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1. Introduction 


This report presents a summary of the accomplishments of this research group over the 
past one year. 

In accordance with our proposal, the achievements of this period of time are: 

- made demonstrations with DHC, a prototype supporting DBSD methodology, for 
Paramax personnel at ODU; met with Paramax personnel on a regular basis to discuss 
DBSD issues, the process of integrating DBSD and Refinery and the porting process 
model (see also Attachment 3 ). 

- completed and submitted a paper describing DBSD paradigm to IFIP ’92, Spain, 
which was accepted and presented; completed and presented a paper describing our 
approach for software reuse at the Software Reuse Workshop held in April 93 in 
Washington, D.C.(see also Attachment 1) 

- continued to extend DHC with a project agenda, facility necessary for a better project 
management. 

-completed a primary draft of the re-engineering process model for porting, defined at 
the requirements level for Paramax re-engineering problem( see attachment 2 and 6). 

- created a logging form to trace all the activities envolved in the process of solving the 
reengineering problem (see also Attachment 7). 

- according to our discussions with the Paramax personnel we have developed a primary 
chart with the problems envolved by the reengineering process ( see Attachments 3, 4, 
5). 

2. Meetings with Paramax personnel 

In this period of time we have met with Paramax personnel on a regular basis to discuss 
DBSD issues, the process of integrating DBSD and Refinery and the porting process 
model and we made demonstrations for them with DHC, a prototype supporting DBSD 
methodology (see also Attachment 3 ). Also, Tammy Taylor (Paramax) demonstrated 
Refinery for the ODU team. 

3. Paper describing DBSD paradigm 

We completed and submitted a paper describing DBSD paradigm to IFIP ’92 
Conference, Spain, which was accepted and presented. We also completed and 
presented a paper describing our approach for software reusability at the Software 
Reuse Workshop held in April ’93 in Washington, D.C.(see also Attachment 1). 



4. Issues in solving the software re-engineering problem 


4.1. The Re-engineering Problem 

Paramax desires a reengineering capability to address the following scenarious: 

- port applications from one machine to another. 

- translate an existing application on a source machine to an application in a new 
language, machine independent so that they can have a kernel version of an application 
which runs on several platforms. 

-enhance the features of an application, extract the best features from several versions 
of a given software system and create one kernel version. 

They will need support for both porting and reverse porting processes since they want to 
keep consistent the 2 versions of a program that has been ported. 

4.2. Approach 
4.2.1. Alternatives 

To address these problems we can adopt one of the following alternatives: 

- build solution from scratch, develop a fully automated, noninteractive system for 
specie cases. 

- develop an expert system using only DHC. 

- integrate DBSD and Refinery into a Unified Environment. 

-adopt some other non-automated tools suited to our purposes(like UNIX ”awk”, for 
example). 

We have decided to adopt the alternative of integrating DBSD and Refinery, since in 
house and local capability exists and Refinery may allow for significant automation 
through use of transformation rules, DBSD creating the environment for recording the 
methodology of the processes performed and the decisions taken during the 
development of these processes. 

For this integration of DBSD and Refinery we see two possibilities: 

- make them loosely coupled, seeing each other like a black box that executes its job 
sequential in time with respect to the other tool. 

- make them tightly coupled, i.e. embed DHC in Refinery or viceversa. For this case we 
need a deep understanding of the source code, capabilities and functions of Refinery. We 
would like to have answers from Paramax to the following questions that would help us 
to figure out the final approach of this problem: 

- which are the capabilities and functions of Refine? Are they noninteractive so they can 
be wrapped into DHC functions, are they sufficiently small to be embedded? 

- how is the precision of decision structure maintained through the Refinery 
transformation? 



Up to now we have developed the loosely coupled version, choosing the simple way of 
porting, in order to better understand the process. 


For example, if we want to port an application from Harris to Honeywell or Microfocus 
Cobol, or Honeywell to Hams or Microfocus Cobol, one should perform the following 
steps: 

- select sample Harris code 

- select functionally identical Honeywell code 

- parse Harris code into Refine object base, generating an Abstract Syntax Tree(AST 1 ) 

- parse Honeywell code into Refine object base, generating an Abstract Syntax 
Tree(AST2) 

- perform manual comparison on programs and components 

- isolate problem areas: 

- areas where there is no one-to-one transfer 

- overlapping of functional modularity. 

- develop Refine code to convert Harris Cobol to Honeywell Cobol 

- develop Refine code to convert Honeywell Cobol to Harris Cobol 

- develop Refine code to convert Harris Cobol to Microfocus Cobol 

- develop Refine code to convert Honeywell Cobol to Microfocus Cobol 

- perform manual completion of the conversion in each of the above cases 

- use DBSD for recording methodology and the decisions taken during the 
development process. 

In the development process one might find decision views attached to the original 
source, decision views attached to the transformation rules or decision views attached to 
the target source. The latest might include decision views attached to the original source, 
decision views attached to untransfered code, decision views attached to new code 
generated during transformation process, mapping of decision views attached to 
transformation rules to the target code. In order to be able to distinguish among this 
diversity of decision views we need to develop in DHC a mechanism for ’’filtering” the 
views. 

4.2.2. Upgrading DHC 

In developing the solutions for the reengineering problem we began to recognize the 
importance of managing problems which are in a state of transition. Problems which 
have not been fully integrated into the document base must be kept visible. A project 
agenda is used to record the state of all problems under active development. This project 
agenda may contain tentative alternate solutions to problems from which an assessment 
can be made. Once a commitment is made, the chosen solution can be linked into the 
document base. So, problems which have been identified but not yet solved are kept in 
the project agenda. Project managers use the information in the project agenda to 



allocate resources to solve these problems. Focusing on this process instead of the 
products of development allows management to control the scheduling of activities. 

4.2.3. The chart of the reengineering problem space 

According to our discussions with the Paramax personnel we have developped a 
primary chart with the problems envolved by the reengineering process ( see 
Attachments 3, 4, 5). It contains the graphical equivalent of the problem and decision 
spaces. The problems in the chart are indexed by the number in the DHC.pd file (the 
problem description file). It includes the problems, alternatives and output of the 
problems, linked together by decision, justification, alternate and output links. 

4.3. Process Model 

In the referred period of time we have concentrated our efforts in creating a primary 
draft of the re-engineering process model for the porting problem, in order to better 
understand it. We have decided to write separate methodologies for porting, enhancing 
and translating because the process is too little understood to fully develop a general 
methodology for everything. This process model addresses the activities and their input 
and output used in creating and using the information necessary to the problem solving. 
By writing an explicit process model, the roles of different members of the software 
engineering team and management is clarified. In addition, it is possible to identify 
desirable functionality for the software engineering environment. 

We have attached the primary draft of the porting problem (Attachment 2) and the 
DBSD process model for the traditional life cycle (Attachment 6), as well as the 
notations used in these two process models. 

4.4. Evaluation Process 

In order to evaluate the conditional decisions during the process of solving the porting 
problem we have created a logging form that will help us to keep a notebook of 
activities, tools used, features applied, the time spent in each activity as well as the 
products of each activity (see Attachment 7). 

All this information will be applied to a statistical analizer that will help us to figure out 
the frequency , duration of each feature, the size of various parts of 
documentation(decisions, transformation rules, source code, BNF rules, etc.), amount 
of new parts vs. changes in existing ones in the dynamic process of this problem solving. 


4.5. Market Study done at Paramax 

In order to complete our research and document preparation, we need answers to several 
questions which are listed below. These questions represent concerns about the market 
which Paramax is serving and expected market conditions for the future. This will assist 
us in defining our reengineering model and associated activities. We request Tammy 



Taylor from Paramax/Virginia Beach to gather the answers to these questions or to put us 
in touch with the appropriate personnel that can provide us the guidance necessary to 
proceed. 

1 . Does Paramax/Virginia Beach and Paramax/Corporate have contracts for porting 
software from one platform to another? If so, how many and to what extent? For 
example, a. How big are the contracts to port in terms of lines of code? b. What 
language are they in? c. What is the value of the contracts? d. What solutions to these 
problems have been used in the past? e. What problems have been encountered with 
these solutions? 

2. In porting software, is the requirement a one to one port? Meaning, are you to just 
move the software as it stands and provide the necessary mechanism for running in 
another environment? If so, once the port is complete, will you be contracted to enhance 
ported software in the new environment? If not, what is the expected duration of the 
ported software on the new machine? (i.e. will it be redeveloped from scratch in the new 
environment? etc.?) 

3. How often do you foresee performing software porting? software translating? and 
software enhancements in the foreseeable future? Anotherwords, what is your 
predicted bussiness direction? 

4. What impact does the Department of Defense (DOD) have in your business goals? 

5. What does the DOD mean by reuse/reengineering? Are you solely driven by the DOD 
requirements? 

6. What are the characteristics of reuse? 

7. What are the characteristics of reengineering? 

8. What types of software systems do you envision the DOD wanting to perform 
reuse/reengineering on? 

9. What are the strategies of DOD for the foreseeable future? 

10. What relation does ICASE play in those strategies? 
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Software Life Cycle Support - Decision Based Software Development 


Chris Wild and Kurt Maly 

Department of Computer Science, 

Old Dominion University, Norfolk, VA 23529-0162 USA 

Abstract 

The software engineering life cycle encompasses a broad range of activities from the initial 
elicitation of the system requirements to the continuing evolution of the operational system. These 
activities can be best supported if there is a unifying paradigm which can integrate functional and 
non-functional problem-solving, process management, and knowledge acquisition and reuse. The 
Decision Based Software Development (DBSD) paradigm structures the software development and 
evolution process as a continuous problem-solving and decision making activity. In the DBSD 
paradigm, the software engineering team identifies and articulates software development problems, 
proposes alternative solutions, develops supporting justifications from which a decision is made. By 
making the problem solving process visible, DBSD allows management to control the creative, and 
sometimes chaotic, set of activities comprising software development. By recording the decisions, 
decision making rationale and the relationships among decisions and between decisions and the prod- 
ucts of software development, the source code and related documents are structured significantly 
different from traditional structures such as the modular or data flow view. This structure asso- 
ciates a decision with only those parts of the documents affected by that decision. These decision 
views support continued evolution of the software system because both the rationale for individual 
decisions are recorded as well as the interrelationships among decisions. Documenting these interre- 
lationships helps the software engineer assess the impact of changing a decision and to understand 
the consistency requirements among a set of decisions. 

Keyword Codes: D.2.0; D.2.2; D.2.7; D.2.9 

Keywords: Software Process; Software Maintenance; Engineering Design 


1 Software Development Problem 

The engineering of large systems is a complex undertaking which requires sound technical methods 
and careful project management. In order to make significant progress in improving software creation 
and maintenance, a better understanding of, and support for, the development process will be 
necessary. By focusing on the software products most approaches to software development do not 
adequately support the design process itself. Non-functional requirements are poorly represented 
by the current software engineering structures. We believe that supporting the design process 
will require a fundamentally different development paradigm which addresses the entire systems 
development life cycle. In this paper, we describe the Decision Based Software Development (DBSD) 
paradigm for systems life cycle support. 

A good software engineering methodology should provide knowledge sources, reasoning agents 
and process management. The purpose of documentation is to capture knowledge for later reuse. In 
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addition, project knowledge is contained in the minds of the software engineering team. Reasoning is 
carried by the members of the software engineering team. This reasoning can be assisted and in some 
cases replaced by software engineering tools. The process describes how knowledge is created and 
used during the development effort. It deals with the management of the knowledge and reasoning 
resources. 

It is our view that automating the project knowledge base will provide the greatest near term 
leverage for addressing software engineering problems. Existing document bases suffer from two ma- 
jor deficiencies. First, not all the critical information is contained in the document base. Traditional 
documents typical only record the results of the problem solving process in terms of the particular 
solutions taken and only if this solution results in a visible product or deliverable. Much of the un- 
derstanding and justifications for making particular decisions exists only in the minds of the original 
developer. This information consists of relationships between different requirements which require 
tradeoffs to be made, promising development paths that later proved to be dead-ends and alterna- 
tive paths that could lead to a better solution if more resources were available to pursue them. The 
person who subsequently uses the document base to make changes, must be able to reverse engineer 
this missing information. The second problem is that the organization of the document base may 
not support easy access to relevant information that is contained there as it is needed. At the very 
least, more effort is expended to locate this information. In the worst case, this information must 
be reverse engineered. Reverse engineering critical information is both time consuming and error 
prone and contributes significantly to the software problem. 

The content and organization of the project document base thus plays a critical role both in 
guiding the initial development and supporting system evolution. During the process of software 
development the software engineer needs access to only a selected subset of information from the 
document base. The subset of information needed to perform a particular task is called the closure 
of that task. The ideal closure contains exactly the information the software engineer requires 
to perform the task. The actual closure refers to that subset of information which the software 
engineer can retrieve from a particular document base. The actual closure is determined by the 
organization of the document base, the set of information retrieval tools available, and the process 
used to build the closure. Much of the effort on structured programming has been to organize the 
program text and development process to support closure based on modular structure and functional 
abstraction. 

The document base should be used to support the development process. This implies that 
the document base contain more than the final products of each phase of the life cycle. In order 
to support the early phases of development, the document base must record the problem solving 
process, even if the relationships between these problems and the final products is not yet clear. 
The development process must allow for easy evolution and maintenance of the document base. In 
addition the documentation effort should not place an undue burden on the developers. Information 
that is easy to reverse engineer, need not be included in the document base. It should be easy to 
add missing documentation and to correct the inconsistency of existing information. 

2 A New Approach: Decision Based Software Development 

The Decision Based Software Development(DBSD) Paradigm has been proposed to support the 
process of software creation and evolution. DBSD belongs to the school of thought that the devel- 
opment process can be modeled as a set of related problem solving episodes [?, ?, ?, ?]. 

Organizing the document base and the development process around problem solving and decision 
making is more general than using data flow, top down design, module decomposition, object oriented 
design or other structured methods. Problem solving is a universal activity which spans the life cycle. 
For example, many of the decisions in determining the requirements are based on weak justifications 
or are made without a full understanding of their consequences. Documenting the decision made 
during the requirements definition would help the designers understand which requirements are firm 
and which could be revised in order to build a better or cheaper design. 
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Example 1 A system requirement stipulates a response time under three seconds for 90% of the 
transactions under worst case loading. Providing the resources to meet this requirement may be 
wasteful if the worst case load occurs extremely rarely or if the three second limit was chosen arbi- 
trarily. 

Both functional and non-functional requirements involve problem solving. Non-functional problem 
solving receives very little attention in most software development approaches. Many of the solutions 
to non-functional problems do not directly result in software products but the provide the constraints 
under which software products are developed. The response time requirement described in the 
above example may be the proposed solution to the problem of keeping the user attention and 
reducing frustration, but it does not in itself produce code. It does, however, affect the choice of 
data structures, algorithms, overall software and hardware architecture and hardware performance 
requirements. Additionally, problem solving is process oriented. Since engineering involves many 
tradeoffs, there will be times when earlier decisions will have to be changed. Documenting the effects 
of these decisions will ease the burden of making these changes both during initial development and 
system evolution. 

Recording the decisions and structuring the document base by these decisions has an additional 
advantage. In initial development, focusing on the identification of problems, alternate solutions and 
justifications provides structure into what is a creative but often unstructured process. The status 
of the progress among all problems is recorded. If a problem has been solved, the decision and its 
justification is recorded together with all its effects. Problems which have been identified but not yet 
solved are kept in the project agenda. Project managers use the information in the project agenda 
to allocate resources to solve these problems. Focusing on this process instead of the products of 
development allows management to control the scheduling of activities. 

The primary advantage to recording the decision structure of a project comes forth during soft- 
ware maintenance. If the software contains a fault it is because at some stage in the problem solving 
process a faulty solution was chosen. If a solution leads to poor performance, then the decision 
which choose that solution must be revisited and an alternate solution should be chosen. When 
adding new functions to a system, the documentation of decisions will help the software engineer 
decide which solutions can be reused. Another advantage of relating documentation to decisions is 
when decisions are changed, those parts of the document base which are affected by that decision 

are more easily accessed and updated. This helps address the problem of keeping the documentation 
up to date. 

The problem solving model is in contrast to the transformational model of development in which 
an initial abstract document describing the system is transformed into an efficient operational system. 
One of the problems not addressed in transformational system is how the initial system description 
is generated. The basic problem solving process involves the following steps: 

1) Identification and articulation of the problem to be solved. 

2) Generation of alternate potential solutions. 

3) Validation and Justification. Before a proposed solution can be adopted, it must be validated 

as a feasible solution and its choice among all the feasible solutions must be justified. This 
justification is done in the context of other decisions and constraints. 

4) Commitment. If there are several alternate solutions, then a decision must be made. This 

decision is justified both by the quality of the solution and by the context in which the decision 
is made. 

Because a solution to a problem may itself constitute a subproblem, the process of problem solving 
is recursive. 

DBSD introduces new information structures into the project document base as shown in Fig. 
??. The decisions are listed on top with the links to the relevant problems visible. In this figure we 
have organized the document base according to the traditional life cycle and hence have grouped 
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Figure 1: Decision Based Software Documentation 


decisions into requirement decisions, specification decisions, etc. However, the DBSD paradigm is 
independent of the software development methodology used and this particular grouping is only for 
illustration. Since solutions to one problem may require further problem solving themselves, decision 
structures are linked together by a problem/solution dependency link. If a decision structure 
references or defines an artifact described in the software document base, a linkage between them 
is made. The decision structure provides a view of the document base which support the problem 
solving process. We call this view of the software document base the decision view. 

Since design involves a careful consideration of tradeoffs among alternatives, decisions are typi- 
cally made in the context of existing decisions, solutions, and policies. Justification links provide 
the context of solutions and other problems in which a decision is made. The structuring provided 
by decisions does not necessarily correspond to the normal presentation structure of a document. 
The Presentation Structure of a document is the organization traditionally used to present the doc- 
ument. This structure may be dictated by documentations standards which detail which sections 
must be present, their contents and relative order or by document processing programs (such as the 
compiler or document preparation tools). The view of a decision may be scattered throughout a doc- 
uments) impacting many parts of it. In addition, several decisions may impact the same part of the 
document. As shown in the figure, several decision views may overlap. Through the problem solving 
graph, one can trace from any document back through the relevant problems to a requirement. Or 
one can trace from a problem to its solution, expressed perhaps as the lines of code which implement 
a solution to that problem. Since requirements, specifications and design documents represent a so- 
lution at some level of abstraction, the problem solving graph provides a view of those documents. 
Also some of the final solutions are not programs. Users manuals and operations guides are part of 
the system solution and can be in the view of decisions. This figure indicates the generality of the 
DBSD paradigm. All phases of the life cycle can be viewed as problem solving from the generation 
of the initial requirements to the source code. In fact, DBSD encompasses other design activities 
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as well. We have applied the DBSD paradigm to the development of its process model. 

In order to gain a better understanding of how DBSD paradigm can be applied to software 
development and maintenance, a prototype DBSD support system, called D-HyperCase , has 
been developed. D-HyperCase is described in [?]. 

3 Process Modeling 

Since problems can arise at any time during development, fitting them into a problem space is 
not predetermined. The organization of this space and the resulting structure of the final software 
system is not given and will depend on how decision making is managed. For example the Spiral 
Model of software development [?], focuses on the high risk problems first which provides the context 
in which less risky problems are solved. Incremental Build delivers a system as a series of products 
with increasing functionality where later versions build upon decisions made during the earlier 
versions. We believe that DBSD is a fundamental paradigm which can be incorporated into diverse 
engineering methodologies. In order to better understand how to utilize DBSD we have developed 
a general process model for it. This process model does not prescribe the order in which decisions 
are made nor the set of documents produced. This process model addresses the kind of information 
to produce and the activities used in creating and using this information. By writing an explicit 
process model, the roles of different members of the software engineering team and management is 
clarified. In addition, it is possible to identify desirable functionality for the software engineering 
environment. 

In developing the process model, we began to recognize the importance of managing problems 
which are in a state of transition. Problems which have not been fully integrated into the document 
base must kept be visible. A project agenda is used to record the state of all problems under 
active development. This project agenda may contain tentative alternate solutions to problems 
from which an assessment can be made. Once a commitment is made, the chosen solution can be 
linked into the document base. In recognition that software development is an on going problem 
solving activity, it is often possible to identify those decisions which are likely to be revisited after 
deployment. One of the major insights in developing the process model for DBSD is development 
of a active role for planned maintenance in the design decision making process. Because decision 
making is often hindered by lack of experience or limited ability to judge the appropriateness of a 
solution, many solutions will be sub-optimum or unworkable. Since in a complex system there will 
be many decisions which will impact the overall performance either favorably or adversely, it can be 
quite difficult to assign credit or blame to individual decisions. We propose that decisions supported 
by weak justifications be validated by instrumenting the solution to collect data which will support 
or refute the decision - a process we refer to as the DIRE (Decide, Instrument, Re-Evaluate) 
method of problem solving. 

Example 2 In a previous example , the response time under a worst case load was required to be 
under 3 seconds for 90% of the transactions . In order to validate or refute the worst case scenario, the 
system could be instrumented to collect watershed statistics. These statistics can help give insight into 
the nature and probability of worst case behavior. Subsequent decisions which affect this requirement 
can now be more informed. 

The process model provides for management of the development team through a series of activ- 
ities. In our model the activities include 

• identification of new problems. 

• interaction with the software engineering environment to understand a problem and its constrain- 
ing context, 

• assessing different methods of solution including reuse of existing solutions 

• review of proposed solutions in a decision review meeting 

• update of the project document base including problems in process 
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• allocation of resources by management to the solution of active problems 

• implementation of committed solutions 

4 Experience 

The original concepts of the DBSD paradigm were developed as a result of a set of experiments 
in performing maintenance tasks on a moderate sized production Navy application program. Since 
these initial experiments, we have built two Software tools supporting the DBSD paradigm. We 
have also developed a general process model for DBSD. To the degree it was practical all these 
efforts were developed using the DBSD paradigm. The following is a summary of what we learned 
from these experiences. More details can be found in earlier publications [?, ?, ?]. 

• We found the reusability often relates to solutions to problems which result in code fragments 
scattered through the modular structure. This particularly true if the solutions are heavily impacted 
by non-functional considerations. 

• The time spent in understanding an existing system consumed the major portion of the effort 
during maintenance tasks (we measured about 80%). Furthermore, understanding the non-technical 
reasons why certain solutions were taken were the most difficult to reengineer. 

• The first software tool was built using a graphical hypertext system developed at Old Dominion 
University. This system was extensively modified in adapting it to our project. The decisions 
structure for the original software was reverse engineered by one of the original systems designers. 
In order to assess the value of DBSD in this effort, a set of metrics were developed to measure the 
differences between the ideal and actual closures. An abstraction metric [?] measures the size of 
the document base associated with a viewpoint. Examples of viewpoints are decisions, modules or 
function points. The number of viewpoints which must be understood in order to perform a task 
defines a related metric called the task abstraction metric. A set of precision metrics measures the 
difference between the actual and ideal closures (percentage of actual closure not in the ideal and 
percentage of the ideal closure not in the actual). During this initial development data was manually 
collected to measure precision and abstraction. These preliminary results [?] indicate that by using 
the decision view instead of a functional view of the software, the software maintainer would be able 
to find the relevant parts of the document base more precisely using fewer abstractions (by a factor 
of 2 to 5). 

• Removal of obsolete code would be easier using the decision view than a functional view of the 
source code document. We believe the same would hold for other forms of documentation as well. 

• We do not expect that it is possible to develop a perfect decision structure. An unstated problem 
or assumption will of course not result in a decision structure. The penalty for changing a system 
with unstated decision is that they will have to reverse engineering during the understanding and 
impact analysis. However once articulated, there is a rapid growth in the precision of the decision 
structure with respect to the new and future related changes. This restructuring is much easier than 
that which would be required by restructuring an inappropriate modular structure for a system. 

• The last observation on the ability to grow and modify the decision structure suggests that it 
should be possible to apply the DBSD method to existing software systems. 

• The additional effort to document the decision structure was measured at an additional 10% in 
keystrokes entered. This reflects the decision to automatically associate the primary decision with 
the document as it is initially entered ( that is, the software engineer, first identifies the problem 
they are working on, then edits the document base. All new entries are automatically associated 
with the current decision). We believe audio data entry would reduce the effort even further. 

• The process model described in [?] is our third experience with DBSD. This effort further shows 
the generality of the DBSD approach. The process model deals primarily with management issues. 
We are currently building a third system which incorporates additional support for the process 
model. In particular, this system will have project agenda management and will help build and 
assess the closure of a maintenance task. 
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5 Conclusions 


The Decision Based Software Development Paradigm offers a new approach to developing and main- 
taining complex software systems. In this approach, the process is organized around the problem 
solving activity rather than the product structure. Our research into the DBSD paradigm has 
addressed the organization of the document base, the functionality of a Software Engineering En- 
vironment and a process model to support it. It provides a different structure of the document 
base which is related to the process which creates and maintains it. This model supports decision 
validation based on the Decide, Instrument, Re-Evaluate (DIRE) paradigm in which the software 
system is instrumented to collect data to validate or refute decisions which are weakly justified. Our 
experiences with the DBSD paradigm indicate that it is sufficiently general to provide life cycle 
support for complex software systems. 
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• D-HyperCase: Prototype Implementation 

• Process Model for DBSD 
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What are the Problems? 


• PROBLEM: Most Documentation Fails to Support the 
Process - 

Document After the Fact, Largely Irreievent. 

• PROBLEM: Functionally Oriented Software Engineering 
Methods - 

Poor Support for Non-Functional Requirements Resolu- 
tion. 

• PROBLEM: Structured Methods Oriented Around Prod- 
ucts - 

Early Stages of Life Cycle, Policy Making. Style Concerns 
Ignored. 


• PROBLEM: Rigid Structures - 
Reusability and Evolution Constrained. 
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Decision Based Software Development 

=> Model the Process of Software Development and Evolution 
as a Set of Interrelated Problem Solving Episodes. 

=$• Record Decisions Made and Their Relationships to Other 
Decisions and to the Products of Software Development. 

Why Problem Solving? 

• Supports Process Across Life Cycle 

• Supports Non-functional Requirements Resolution 

• Process Oriented 

Why Record Decisions 

• Decision Rationale Difficult to Reverse Engineer 

• Record Promising Alternate Solutions and Dead Ends 

• Engineering is Trading Off Decisions 

• Software Maintenance is Changing Decisions 
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Fig. 1 Decision-Based Software Documentation 
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Software Maintenance Life Cycle 


Understanding: 

What problems are addressed? 

How are they solved? 

Why was this solution chosen? 

How are the parts of the system interrelated? 

Impact Analysis: 

What parts of the system are affected by a decision? 
What decisions impact a particular part of the system? 
What Level of Effort is Required? 


Redesign: 

Justify and Commit Redesign 

What parts of the system can be reused? 

What parts are now obsolete? 

Is the modification consistent with the rest of the system? 

Validation: 

Does the System satisfy its requirements? 

If not, which decisions must be changed? 
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Process Modeling 


Process: 

• Set of activities 

• Relationships among Activities 

• Team Structure and Responsibilities 

• Role of Software Engineering Environment 

• Policy and Constraints 

• Resource Management 

Process Model: Formalization of a design method which 

• Provides notations amenable to analysis 

• Encompasses breadth and depth of software developmenr 

• Assists in management - defines milestones 

• Provides heuristics/algorithms for well-understood situa- 
tions 
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Process Model for Traditional Life Cycle 
Detailed Description 


External _customer ^requirement _resolution C u -> task cu > (Software_development I Customer feedback) > 
system 

Internal _perf ection_and_correcuon CVMA --> taskc UMA > Software_development > system 

Software_development — > task > ( Understanding 

Understandings F _) >/*requirements_definition*/ task_root: task_problem 
/*list_of_reusables candidates*/ {problem}, 
Task_problem_solving > /*first_level_decomposition*/ { task_problem), 

{Afjcjj/«c/if M/JJ£ > (task_root, effort, task_root.size, task_root.risk) Change_task_decision > task root) 

Assign_resources > schedule 

Transfer_task_to_problem_space > agenda 

{agenda; schedule > Solve _problem S E > agenda 

Review_meeting > meeting_notes 
Implement_meeting_decision > schedule, agenda) 

Understandings SE --> Exploring 1 1 add_to_reporl MA SE > report 

Exploring ~> Requirements_definition II Reusability_search 

Requirements.definition --> (keywords > Iocate_problem > relevant_nodes: (problem), 

make_ne%v_requirement) > task_root_problem 

V relevant_nodes > Understand_problem 

Understand_problem — > problem >{ ( Visit_node dependency_up > problem) 

I tcrniinatc_at_node_closurc_relevant_nodes 
I back ) 

/*exploration*/ (justification_from > problem 
I justification_to > problem 
I dependency_up > problem 
I dependency_down > problem) 
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Managing Deferred Decisions 


• Problem Not Adequately Understood 

• Solution Identified First 

• Inadequate Justification 

• Instantiating a More General Problem 

• Inadequate Resources 

• Unexpected Opportunities 

• Inexperience 
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DIRE - Decide, Instrument, Re-Evaluate 
Problem 

• Engineering Tradeoffs involve many interacting decisions. 

• Inexperience affects quality of some decisions. 

• Impact on overall performance of decisions may be difficult 
to determine. 

Solution 

• Identify decisions with “weak” justifications. 

• Minimize the impact of these decisions (minimize justifi- 
cation links). 

• Instrument system to validate or refute this decision. 

• Re-evaluate decision using data collected from operational 
system. 
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Evaluating the Process Model 


• Assess degree to which the objectives have been met 

• Develop a better understanding of the dynamics of the 
process 

• Identify what pieces of information are needed and when 

• Develop a methodology for DBSD 

• Identify where tools could be applied to improve the pro- 


cess 
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Interval of Evaluation 


Main purpose of evaluation is self improvement. 

Balance progressive and anti-regressive activities. 

Four intervals of evaluation: 

System Life Time: A cost/benefit analysis is done over the 
life time of the entire system. 

Release: Most large software systems go through a set of re- 
leases over its life time. Each release usually represents a 
significant change in the syste?n in which major problems 
are rectified and new features are added. 

Task/Change Order: A task represents a unit of work to 
be performed. A task could be defined in response to a 
trouble report or could represent the addition of some new 
feature. 

Session: A session represents a contiguous period of time dur- 
ing which the programmer is working in the development 
environment. 
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• Is there 
tasks? 


a working set model for software maintenance 


• How are the dynamics of the process affected by the task 
type (corrective, perfective, adaptive)? 


• What information was found useful in 


performing a task? 


♦ What are the different information needs of Managei 
software Engineers, Others? 


\s. 


• What information was missing or difficult, to access 

• How can consistency be maintained? 


Session/Tasks Measures gathered: 

• Sequence of decisions visited 

• Sequence of commands issued 

• Time spent in each view 

• Keystrokes entered 
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Summary of Recent Experiments 


Data Goilected over 43 Sessions Resolving 10 Maintenance 

• Additional Documentation Effort for the Decision Struc ' 
ture is about 10%. llC ' 


About S0% of Time was Spent in Reading This Doc 
tation. 


umen- 


* A b ° Ut ° f ThC Accesses To The Document Base Were 
Through The Problem Views. 


The failure rate of reused code was 5 t 
code. 


imcs less than new 


’ inv7 g ‘ 1 lf> de ? i f 0n °" CUrS ° r position second window 

315 LOP l! f et 0n0fone problem view contained 
S in 2 d functions (containing a total of S92 LOCs). 

hoX^Tmes ainteHanCe taSkS are m0re ‘ 0Cali2eti Witil hi « h 
hoMingIhnes. intenanCe ^ “““ VieWS with 


Adaptive Tasks access a few 


times then create new views with high holdi 


views with short holding 


ng times. 
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Future Directions and Work In Progress 

• Create Version 2 DHC - Agenda and Task Management 
Support 

• Prepare Guide Book Based on Process Model/DHC 

• Undertake Empirical Evaluation of Process Model 

• Study Support for Reusability 

• Active Environmental Support for Process Model 
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Conclusions 


• To perform a given task, the decision viewpoint requires 
fewer conceptualizations than the functional viewpoint. 

• These conceptualizations are more precise in identifying 
the relevant parts of the document base for revision. 

• DBSD helps control the sometimes chaotic creative pro- 
cess of software development. 

• Non-functional requirements play an important, role in the 
problem solving process 

• Explicit Process Model clarifies roles for Software Engi- 
neers, Managers. Operators and Software Tools. 

• Software Engineering Environment should support Pro- 
cess Model. 

• Software System should be instrumented to collect infor- 
mation to validate/refute critical decisions 
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Closure 


Ideal closure: exactly those portions of the document base 
which are relevant to the task. 

Actual closure: depends on the structuring method and 
the granularity of view point it imposes on the document base. 

Precision: 

The degree of match between the actual and ideal closures. 

Relevance: The percentage of the actual closure which is in 
the ideal closure. One minus the density is a measure of 
the "noise” in the actual closure. 

Oversight: The percentage of the ideal closure which is not 
in the actual. 
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Abstraction 


The representation of a set of related concepts as a single 
unit. If this representation helps in the understanding of the 
set of concepts then it is an appropriate abstraction. 

Size: One measure of an abstraction is the size of the problem 
it conceptualizes. The metric used in our evaluation is the 
number of Lines Of Code (LOC) related to the abstrac- 
tion. 

More LOC => More Abstract. 

Power: For a given task, the number of abstractions needed to 
understand and solve that task is a measure of the power 
of the set of abstractions. 

Smaller Sets => More Power. 
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Using DBSD Approach 

• Make the Solution Visible. 

Work Through a Particular Task. 

• Identify the Problems That Each Solution Solves. 

• Generalize the Problem, if Appropriate. 

• Uncover the Underlying Assumptions Which Justify the 
Particular Solution. 

• Develop Alternate Solutions. 

• Justify the Assumptions. Pick the "Best Solution. 

• Link the Identified Problems and .Justifications. 

• Place Incomplete Decisions on Project Agenda 
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Cost - dwindling budget - increased demand on increasing productivity 
and reliability. - competiveness. 
loss of intellectual control of process. Points: 

• paradigm justification 

• DBSD 

• DHC 

• Evaluation purpose 

• results 

• methodology and process 

- management controls temporal aspects, resources and defines non-technical 
constraints - interleave VG - management is process of making decisions - 
dynamics of decision making - solution w/o problem, SP wo alternates, al- 
ternates wo solution, no justifications - degree of satisfaction If time show 
them performance req. and DO without solution and justifications are hy- 
pothetical. 

1. do nothing 

2. change req. 

3. temporary release from req. 

4. tune program 

5. redesign 

-DO create interleave for this set of decisions. No justifications for choosing 
yet. limited resources could push for 2 or 3. TO choose between 2 and last 
two need to know if it scales (complexity constant, linear, exp.). Points up 
that alternates are part of the agenda. 
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OUTLINE 


• Software reuse terminology 


• Decision Based Software Development Approach 


• Decision Based Software Development in the Reuse 
Arena 
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ABSTRACTION 

What type of software entities are reused and what abstractions 
are used to describe them? 


Reusable code: 

• reusable data-centered components (Ada: stacks, lists, strings, 
queues,sets, trees, etc); 

• reusable function-centered components(sorting, searching). 

Software Schemas (formal extension to reusable software components) : 

• the emphasis is on reusing abstract algorithms and data 

structures 

• each schema has a specification that includes: 

• a formal semantic description of the schema 

• assertions for correctly instantiating the schema 
(constraints on the variable part of the schema) 

• assertions for the valid use of instantiated schema 
(preconditions, postconditions) 

Application Generators: 

• reuse complete software system designs (expert systems 
generators, compilers generators, etc.) 

Very High-Level Languages: 

• can be viewed as specification languages when compared with 
high-level languages (executable specification languages) 

• mathematical abstractions (set theory, constraint equations) 

Transformational systems: 

• development histories that can be replayed (PADDLE, Glitter) 

• transformations : mappings from syntactic patterns of code into 
functionally equivalent, more efficient patterns of code. 

Software Architectures: 

• large grain software frameworks and subsystems that capture 
the global structure of a system design 
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SELECTION 

How are reusable entities selected for reuse? 


Reusable code: 

• techniques for describing the components (formal annotations - 

Anna) 

• techniques for classification and retrieval (different indexes) 

Software Schemas: 

• sophisticated searching at the abstraction specification level 

(PARIS) 

Application Generators: 

• libraries of application generators have not been developed yet 

Very High-Level Languages(VHLL): 

• selecting the VHLL that is most appropriate for a particular 
application 

• selecting the language constructs that best represent the 
application 

Transformational systems: 

• expert systems technology to select from a library of 
transformations (Glitter) 

Software Architectures: 

• library techniques 
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SPECIALIZATION 

How are generalized entities specialized for reuse? 


Reusable code: 

• by directly editing the code 

• parameterized macro expansions 

• Ada generics 

• inheritance 

Software Schemas: 

• substitution of language constructs, code fragments, 
specifications, or nested schemas 

• choosing from a predefined enumeration of options 

Application Generators: 

• by providing an input specification. The techniques used 
depend on the application domain abstractions: grammars, regular 
expressions, graphical languages, interactive dialog,etc. 

Very High-Level Languages: 

• parameterized language constructs that are specialized by 
recursively substituting other language constructs 

Transformational systems: 

• not an issue, typically 

Software Architectures: 

• horizontal: source-to-source transformations (optimizations in 

Draco) 

• vertical: component refinements (alternative implementations 
with different performance characteristics) 
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INTEGRATION 

How are reusable entities integrated to create a complete software 
system? 


Reusable code: 

• module interconnection languages 

Software Schemas: 

• module interconnection languages 

• semantic specifications to compose schemas: 

• horizontal composition corresponds to schema 
composition using nested schemas 

• in vertical composition higher-levels of abstractions 

are created. 

Application Generators: 

• do not require integration 

Very High-Level Languages: 

• encapsulated computation (computation within a function is 
influenced only by its input parameters and return values from the functions 
it calls)- PAISLey 

• order-independent specification and compiler-generated 
control flow and data flow - MODEL 

Transformational systems: 

• implicit in the order in which the transformations are applied 

Software Architectures: 

• special purpose module interconnection language 
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Decision Based Software Development. 

=> Model the Process of Software Development and Evolution as 
a Set ol Interrelated Problem Solving Episodes. 

=* Record Derisions Made and Their R.elal ionships to Other De- 
cisions and to tin* Products of Software* Development. 

Why Problem Solving? 

• Supports Process Across Life* Clyde 

• Supports Noil-functional Requirements Resolution 

• Process Oriented 

Why Record Decisions 

• Decision Rationale Difficult to Reverse Engineer 

• Record Promising Alternate Solutions and Dead Ends 

• En gineeriug is Trading Off Decisions 

• Software Maintenance is Changing Decisions 
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Software Maintenance Life Cycle 


Understanding: 

What, problems are addressed? 

How are they solved? 

Why was this solution chosen? 

How are I lie parts of the system llitei I ela.l et 1 . 

Impact. Analysis: 

What parts of the system are affected hy a decision ? 
What, decisions impact a particular part of the system? 
What. Level of Fdlort is Required'? 


Redesign: 

Justify and Commit Redesign 

What parts of the system can be reused ? 

What parts are now obsolete? 

Is I, lie modification consistent with the rest ol tin* system? 
Validation: 

Does the System satisfy its requirements? 

If not, winch decisions must be changed? 
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Process Modeling 


Process: 

• Set of activities 

• Relationships among Activities 

• Team $1. rueture and Responsibilities 

• Role of Software Engineering Environment 

• Policy and Constraints 

• Resource Management 

Process Model: Formalization of a. design method which 

• Provides notations amenable to analysis 

• Encompasses breadth and depth of software development 

• Assists in management - defines milestone's 

• Piovides heuristics/ algorithms for well-understood situations 
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Summary of Recent. Experiments 


Data Collected over 43 Sessions Resolving 10 Maiiitena.nce 'Tasks. 

• Additional Documentation Effort for the Derision Structure is 
about 10%. 

• About S0% of '.rime was Spent in Rending 'This Dornnienl a- 
tion. 

• About 90%. Of The Access<’s To Tin 1 Document Base Were 
Through The Problem Views. 

• The failure ra te of reused code was 3 times less than new code. 

• Changing decision on cursor position in second window in- 
volved the deletion of one problem whose view contained 3 In 
LOC’s in 25 functions (containing a. total of 892 LOCs). 

• Corrective' Maintenance task's are more localized with high 
holding times. 

• Perfective Maintenance tasks access many views with high 
holding times. 

• Adaptive Tusks access a. few views with short, holding times 
then create new views with high holding times. 
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Closure 


Ideal closure: e-xacfly those portions ol I, lie doe-umeut base which 
arc relevant, to tlic task. 

Actual closure: depends oil the structuring method and the 
granularity of view point it imposes on the document base. 

Precision: 

The degree' o( match hel.wee'U the actual and ideal closure's. 

Relevance: The percentage of the actual closure' which is in the 
ideal closure. One' minus the density is a measure of the 
“noise' 1 ’ in the actual closure. 

Oversight: The percentage of the ideal closure- which is not in the 
actual. 
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Abst raction 


Tlic rfiprosenl-.af.ion of a set of related concepts as a single unit., If 
(, Ins ropi esentation helps in Mir understanding of I he set of concepts 
Uuui if is an appropriate abstraction. 

Size: One measure of an abstraction is the size of the problem 
if conceptualizes. The metric used in <>ur eva.lua.tiou is the 
number ol Lines Of Code (LOG) related to the abstraction. 
More LOG => More Abstract. 

Power: For a. Anvil task, the number of abstractions needed to 
understand and solve that task is a measure of the power of 
the set. of abstractions. 

Smaller Sets => More Power. 
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DBSD IN TFIF REUSE ARENA 


Abstraction: Which entities do we manipulate and store? 

• high level objccts(specifications, requirements, designs) and 

source code (see page 31) 

• in DBSD these objects are represented as: problems, 
alternatives, evaluations, decisions, justifications (see pages 17.I8.19) 

• the granularity ol the objects reused is not influenced by the 
syntactic constructs of the source language used, but by the abstraction level 
of decisions made. 

• DBSD allows not only the reuse of completed products, but also 
to reuse or replay the process used to obtain the product. 

• DBSD is not centered on functional decomposition or other 
traditional methods, it provides a complementary approach by its 
non-linear view of the problems. 


Selection: How do we best identify the components most relevant to a 
given user’s needs? 

What kind of taxonomies and search strategies do we provide? 

• Library techniques: faceted representation, search 

with a similarity measure 

• graphical browsing (see pages 20 . 21 . 22) 

• hypertext (see pages 23.25, 29. 11 ) 
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FUTURE DEVELOPMENTS 

• Specialization: How do we customize a selected generic entity? 

• selecting a value from a precomputed list of alternatives 

• transforming an abstract program schema using a set of 
transformational rules 

• inferring a value using a set of heuristic design rules and/or 
algorithms. 

• Integration: What techniques of program composition do we use? 

• domain-specific rules 

• expert systems technology 

• Management: assessment of reuse 

• associating views to source and documents we can exactly 
identify those components relevant to a solution . 

• we can identify all the components impacted by a view and 
estimate their size, complexity, efforts, etc. (see page 32 ) 

• from a specific retrieved component we can select only the 
relevant parts to the current problem. 
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DHC OUTPUT IN LATEX 

PROBLEM: reengineering.problem 

Develop a methodology and supporting tools to port applications from a 
source machine to another target machine, to translate from language A to 
language B and to enhance existing applications. 

ALTERNATIVES: 1) Develop a fully automated, non-intcractive sys- 
tem for specific cases, (for example, an Expert System for transforming a 
COBOL program) 2) Develop an expert system using only DIIC. 3) Develop 
an interactive system using both DIIC and Refinery, d) Non-automated sys- 
tem for a specific casc.(like ”awk”) 

DECISION: 3) Develop a Uecnginecring.process.modcl, a running, effec- 
tive DUC-prototypc, make Refinery part of the environment, and link DIIC 
and Refinery into a Unificd.environment. 

JUSTIFICATION: Dictated by : a. the availability of DIIC and Refin- 
cry , it will be a matter of evaluation (see Evaluation. problem) b. validation 
of the above decision 
EVALUATION: 

UPLINKS: apply_and J in p rove. D BSD .methodology 
DOWNLINKS: porting.problcm translating.problem enhancing.problem 
PROBLEM: reenginccring.proccss.modcl 

Develop a process model for porting,translating and enhancing applications 
ALTERNATIVES: 1) Develop separate methodologies for: a. Porting to 
different dialects of COBOL(e.g. Honeywell to Microfocus) b. Enhancing 
applications (c.g. using SQL language instead of file operations) c. Trans- 
lating into another language (c.g. COBOL to Ada) 2) Develop a general 
methodology for everything. 

DECISION: 1) 

JUSTIFICATION: The process is too little understood to fully develop 
a general methodology for everything. 

EVALUATION: We assume that the existing application is partially 
D IlC-cd. 

UPLINKS: simple.porting 

DOWNLINKS: process. model .implementation proccss.model.notations 
get.Refinery.process.model get DJIC.proccss.modeLfor.R.enginccring com- 
bine. DIIC Rfinery.process.modcls 
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DHC OUTPUT IN LATEX 

PROBLEM: reengineering-problem 

Develop a methodology and supporting tools to port applications from a. 
source machine to another target machine, to translate from language 1,1 to 
language L2 and to enhance existing applications. 

ALTERNATIVES: 1) Develop a fully automated, non- interactive sys- 
tem for specific eases, (for example, an Expert System for transforming a. 
COBOL program) 2) Develop an expert system using only DHC. 3) Develop 
an interactive system using both DHC and Refinery. '1 ) Non-au tomated sys- 
tem for a specific case. (like ”awk”) 

DECISION: 3) Develop a Recngincering-process-model, a running, effec- 
tive DHC-prototypc, make Refinery part of the environment, and link DHC 
and Refinery into a Unified-en vironment. 

JUSTIFICATION: Dictated by : a. the availability of DHC and Refin- 
ery; it will be a matter of evaluation (see Evaluation-problem) b. validation 
of the above decision 
EVALUATION: 

UPLINKS: apply-and-im prove- D BSD- methodology 
DOWNLINKS: porting-problem translating-problem enhancing-problem 
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DHC OUTPUT IN LATEX 


PROBLEM: reengineering- process- model 

Develop a process model for porting, translating and enhancing applications 
ALTERNATIVES: 1) Develop separate methodologies for: a. Porting to 
different dialects of COBOL(e.g. Honeywell to Microfocus) b. Enhancing 
applications (e.g. using SQL language instead of file operations) c. Trans- 
lating into another language (e.g. COBOL to Ada) 2) Develop a general 
methodology for everything. 

DECISION: 1) 

JUSTIFICATION: The process is too little understood to fully develop 
a general methodology for everything. 

EVALUATION: YVc assume that the existing application is partially 

DHC-ed. 

UPLINKS: simple-porting 

DOWNLINKS: process- model-im piemen tat.ion process- model- notations 

get- Refinery- process- model get- DHC- process- model- for- Ren gin eeri ng 

combine-DIIC-R.fi nery- process- models 




.Sol'lwaic Ri’iisc Wt iik. '.Imp, April 199.1 


19 





SoCiw.'iir Moist'- Wnikslmp. April !W 


20 












Depart mail of Compilin' Science 



Snli-.v.-m- Rouse Workshop. April 1993 




























Miff 

*0 


Department of Computer 



vlng 



Soliv/nri' Reuse Woikslmp. April 


l‘W 



22 





















Dcp.-ulmcnl of Compulcr Sctci 


reengineering-problem 

reengineering-process-model 

evaluation-problem 

logger 

statistical-anal lzer 

apply— process— model— to— transf ormat ion— task 

Preserve-decision-structure-in-AST 

Precision-of-decision-transformation 

new-code-added-by -transf or mat ion-rule 
transformation— rule— decision— v iews 
manual-after-transformation 
tool-for-upgrading-DHC 
robustness— of- DHC 
order-of-objects-editing 
insert-agenda-1 1st 
modify-agenda-1 1st 
! entry— def ini t ion 

i field-definition 
( empty-field-definition 
i app ly -and- improve-DBSD-methodo logy 

3 long-term-goals 
7 reuse-problem 
3 Al-appl ications 
3 porting-problem 
D enhancing-problem 

1 translate-problem 

2 simple-porting 

3 complex-porting 

4 market-study 

5 reengineer ing-contracts-characteri sties 

6 reengineering— so lut ions-character i sties 

7 process-model-implementat ion 

8 notations-foi — process-model 

9 get-Ref inery-process-model 

10 get-DHC-process-model-f or-Rengineer ing 

51 combine-DHC-Ref lnery-process-models 

52 analyze-log-on-Process-Model 

53 analyze-log-on-Unif ied-Environment 

54 analyze-log-on-DHC 

35 analyze-log-on-Ref inery 

56 demonstrate-process 

37 demonstrate-DHC 

38 demonstrate-Ref inery 


F~%%-Emacst dhc-index . ldx - p____^fjjndarf^nt a 1 > - 

zm 


raph 


: upl ink, d : dounl ink, c:current, l:latex. 
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Kurt Maly and Chris Wild 
Short Form 


. BNF PRODUCTIONS 


Customer_requirement_resolution > Sof t W are_development I I Customer_f eedback 

Internal_development — > Sof tware_development 

I. Sof tware_development — > (Understanding_needs MA,SE 
Modify_or_create_new_task SE 
Calculate_ef fect_and_costs MA,SE 
Assign_resources_to_schedule MA 
T ransfer_task_to_problem_space SE) 

I I (Review_meeting_reports_and_progress MA,5t 
Delete_decision_and_replace MA,SE 
Implement_meet ing_decislon MA, SE ) 

4. Understand! ng_needs — > Exploring_needs II add_to_report MA,SE 

5. Exploring_needs — > Requirements.def inltlon Create_and_add_neu/_task_problem \ 

F i nd_and_add_reusab 1 e_node 

6. Requirements_def inition — > (locate_problem I make_neui_requirement ) 
Understand_problem_l inks 

7. Understand_problem_l inks — > C(Visit_and_read_node dependency_up ) 

1 I terminate_at_node_closure_relevant_nodes> 

I ( Justif ication_f rom 
I justif icatlon_to 
I dependency_up ) 

8. Visi t_and_read_node — > read_descr iption document_view Read_document Read_ju\ 
st i f icat ion 

9 Read document — ) C(sultch_vieu I scroll_v iet») I emacg^comn^ndj 
ju^up 1 1 a te™7 g ‘^ aphT^form^^^'ndex , p ; process 7 
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ROBLEM: reengineering-problem 
Develop a methodology and supporting tools to port applications from a source \ 
achine to another target machine, to translate from language LI to language L2\ 
and to enhance existing applications. 

iLTERNATIVES : 1) Develop a fully automated, non-interactive system for specif 1\ 

c sses . 

for example, an Expert System for transforming a COBOL program) 

2) Develop an expert system using only DHC. 

3) Develop an interactive system using both DHC and Refinery. 

4) Non-automated system for a specific case. (like "auk") 

;5£ISI0Nj 3) Develop a Reengineering-process-model, a running, effective 
HC-prototype, make Refinery part of the environment, and link DHC and 
.efinery into a Unif ied-environment . 

USTIFICATION : Dictated by : 

a. the availability of DHC and Refinery; it will be a matter of evaluat\| 
on (see Evaluation-problem)§ 

b. validation of the above decision 
:VALUATION; 

JPLINKS: apply— and- improve- DBS D-methodologu 

JOWNLINKS: porting-problem 

translating-problem 
enhanc i ng-prob 1 em 


AA^Emacs : dlic-tgort: . trmn . < Fundaments 1 ) - 


10 link selected 
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smacs: E macs & wurttemberg 

•velop ^proces^mode 1 r ? or S port ing , trans 1 at i ng and enhancing applications 

TRNATIVES^^l^ Develop^separate^methodologi^es^for:^ ?1 focus) 

b. Enhancing applications (e.g. using 5QL language instead of file oper 

c. Translating into another language (e.g. COBOL to Ada) 

2) Develop a general methodology for everything. 

5TIFICATI0N: The process is too little understood to fully develop a generalN 

ethodology for everything. n u r _ a H 

ALUATION: We assume that the existing application is partially DHC ed. 


LINKS: simple-porting 

UNLINKS : process— model— implementation 

process-model -notations 
get-Ref inery-process-model 
get-DHC-process-model-f or-Rengineer ing 
combine-DHCaRf inery -process-mode Is 


JJX-Emacsri’ dhc-text . t m 




(Fundamental > -w 
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%%-Eroacsr dhc-text . tm 


( Fundaments 1 > 


current. l:late>o 



: index 


Sr.iivv 
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Name: Chenglin Zhang 


DHC LOGGIA FORM 


Comments : an experimental logging Torn 


^**^i* U Process Object Process Model Start Time 


re-eng process write-document BHF rules 

detailed process wr 1 te-document BNF rules 

Unique-name write-program Lisp source 

dhc-brow9 i ng-demo Change_problem Problem 

|dhc -browslng-demo Add.problem Problem 


re-engineering Feb 10.1993 0:OOp 

dhc process Teb 19.1993 9:30am 

dhc-process Feb 20.1993 7:20pm 


Feb 10. 1993 1 1 : iOpmaa 
Feb 19.1993 12:00pm&fl 


dhc-process Feb 20.1993 7:20pm Feb 20.1993 12:30pmfta 

dhc general Ued Opr 14 12:33:43 1993 Wed Apr 14 12:56:23 1993a* 

dhc general Frl Opr 16 16:16:32 1993 Fri Opr 16 16:16:53 1993B* 
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\ 

N 

justification 


justification 

/ 

/ / 



relevant 
node . 


/^generic 

/ i r 

i 


\ problem tags lists 


] 1 ouT] reuse] 1 new] 


\ / 

a 


task_probIcm 


task ^problem J 


tnsk_problcmJ 


new problem not obtained from modifying existing problem 


Key: task relations 
problem tags lists 
dependency relations 
justi feat ion 



entalive task problem space and existing problem space. 










Department of Computer Science 


ODIJ 


DHC Process Model 


ftwarc_dcvcIopmcnt — > task SF ^ A > Understanding ^ /* requirements definition*/ 
task_rooL task ^problem > (problem) /*iist_of_rcusabIc candidates*/ 
Task_probIcm_soIving > ( task ^problem ) /*firsMcvcl_dccomposition*/ 
{Assessmcn{ MA > (lask_root, effort, ta.sk_root.sizc, Uisk_rooLrisk) 
Changc_task_dccision > task_root) 

Assign_rcsourccs > schedule 
Transfcr_task_to_problcm__spacc > agenda 
(agenda; schedule > Solve jyroblcm^ F > agenda 
Rev icw_mcc ling > mccting_notcs 
ImpIcmcnt_mccting_dccision > schedule, agenda) 
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DHC Process Model 


3 ring -> Rcquircmcnts_dcfinition 1 1 Reusability _scarch 

-> ott* > scarch.space > -J— — 

^b^iving -> » * l«* « 1 » > " -J “‘ OT ’ 

{taskjroot > Create jiddilionaljtcwjask > laskjjroblcm}) 

dir, existing node -> notlc > «rent.Jn»*.P^n. > ^.P-obient. «*«**» •»* J™'*"* 1 '™ > ’ 

(Add.ncw.fcautrc I Dcttc.1d.rcMn: I Changc.otdjcatn-c I Copy.gcnenc 

1 Add_rcusc /* for all nodes on reuse list) 

d.rcusc -> change.dcscriplion ad,«U— » 


Softwarr Room: 
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DHC Process Model 


cssment ~> CalcuIatc_Dircct_Effcct CaIculatc_Indircct_Cost Review_Data MA 

culatc Dircct Effect -> V (task e task_problcm } V (task_nodc e task.gcncric U task.out U task. reuse) 

> calculatenodesizc calcuIateriskefTort > (task nodc) 

V {task_ncxlc e new) > gct_cffort_ri.sk_si7.e_estimatcs > (task node) 

V (tasknodc e modify) > Assessment > (task_nodc) 

(task_nodc) > calcuIate_task_problcm size > task 

/* for each category add the number in the subproblcm nodes 

to obtain the relevant figures in the task problem node*/ 

(task_nodc) > caIculatc_task_problcm effort > task 
/* this is the sum of the efforts in the subproblcm list */ 

(task nodc) > caJcuIate_task_probIem_rLsk > task 
/* the sum of the risks in die subproblcm nodes */ 

(task) > add_up_dirccf_cosLs > task_rtx)t 

cuIatc_Indircct_Cost ~> rc!cvanl_nodc > R ct_closure_list Justification Jo from > ripple list: (problem) 

(/* get the worst possible impact by calculating the transitive impact closure for the justification limits */ 
V (notice ripplcjist) > c:ilculalc_total_n(>de_si7.c > (lask_problcm. upper bound) 

/* add up all the metrics, II problems. flLOCS. etc, for all the nodes in the closure */ 

/* allow for interactive estimates */ 

lv (nodee ripplc_list) > (Sclcct_nodc calculate total node size) > { task_problcm.lowcr bound ) 

/* add only selected nodes to the calculation */ 

(taskj)robIcm) > add_tjpjndirect cost > t ask root 
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ACTIVITIES 

(non-terminals) 

Add-conditional-decision 

Add-info-to-nodc 

Add-new-featnre 

Add-problcm 

Add ‘Unconditional- decision 

Adjust-agenda 

Adjust- and-add- reuse 

A ssi g n - re s o 1 1 r ces- to- s c h od h 1 e 

C a! nil a. to- D i reel - F> flee t 
Calculato-IndirecM Ast 
Calciiiate-eRect-and-cost.s 
Change- conditional -decision 
Change- old - featn re 
Change-problem 
( - ha nge-u n conditional-decision 
Copy- gen eric 

Create- ad d i t i o n al - n e w - 1 a s k s 

Create- and- add -new- task- problem 

Customer- recpii rcincn t- resolution 

Delete- decision -and - replace 

Deletc-old-feature 

Exploring-needs 

l ) 'ind-and-a.dd-reusable-node 

Generate- problems 

Implement- meeting- decisions 

Intcrnal-develoi)inenl. 

Locatc-decision 

Locate- parent 

Lora.te-p roblem 

M ako-decision- using- a lU'rnati ves 

M ake- nod e- and - a d ( I - i n fo 

Mod i fv-o r- c rea t e- new - 1 as k 

Mndify-ta.sk-node 

Pick- node-lin k 

Rea.d-doc.nm ent 

Read-justification 

Read - nod e- description 

Re q ii i re in e n t s - d e fi n i t i o n 


R oview-agetidn. 

Review- meeting- reports- and- progress 
I{ eview- reports- a gen da- and -sciied u le 
Select- and- read -node 
Software-development. 

Solvo-problem 

Tr a n s fe r- 1 a s k - 1 o- p r o I > 1 cm - sp ac e 

Understand -problem -links 
Understanding- needs 
Visit-an (1- read- nod e 
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FEATURES 

( terminals) 

ad r I ■ - age n cl a- p r o b I e m 
a<ld- justification 
add-reusoable-nodc 
add -to- generic- list 
add-to-modify-list 
ad d-to-new-list 
add-to-notes 
add-to-out-list 
add -to- report 
add -to- reuse- list 
a.dd-up-dircct-costs 

ad d - 1 1 p- j n d i rec t - cos I 

adjust-justification 

ad just-reuse-task- problem 

browsing-agenda 

ca l c u I a. t e- n od e- s i ze 

ca.Icii late- risk-effort 

calr u late- ta.sk-problenis-efiTorl. 

caJcuIate- task-problems- risk 
ca.ini late- task- problenis-size 

ca J c 1 1 1 ate- tot al- n od e- s i ze 

change-description 

conditional-decision 

copv-new-generic- ta.sk-prr)l)leni 
create-new- problem -node 
create- new- ta.sk- problem 

create- task- problem 
decision 

delete- agon da.- problem 

delete-problem 
delete- task-problem 
dependency-down 
dependency-up 
describe- alternatives 
describe-problem 
document-view 
erna.es- commands 
b II- i n-dcscrip t ion 

get-closure- list- justify- to- for m 

get-effort- risk-size-est i rnat.es 
get -parent- node 


give-justifications 
justification - from 
justification- to 
key- s ii bp robloms 
link-justification 
locate- problem 
lorate-dec'ision 
locate- parent 
make- decision 
make- new - repla.com on t 
mod ify-ageiul a- problem 

problem 

produce-schedule 
read- description 
research- problem 
review- agenda, 
review- report 
review-schedule 
sc roll - view 

select -alternatives 
skip 

switch- view 
take- agenda- problem 

task 

romiina tr-a t-nodr-r.losiirr- relevant, -node: 

tra.nslfv--triita.tivr- to- problem -spare* 

u moil dition a I - decision 
write-and-li n k-docii mentation 

non-dbc FIiA'rUIiK.S 
access- repo r t 
add-direct -costs 
add- indirect- costs 
add-tn- report 
calc u I ale- node- size 
calcula.te-risk-efTort 
ralciilato-lask-proMem-cfrorl. 
rale ii la.tr- task- problem- node 
ralr ula l.e- task- problem- rj.sk 

(Mna.cs-commands 
get-eflort-node-size-estimal.es 

make- new- requirement 
produce-schedule 
review-schedule 
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ACTIVITIES 

(non-terminals) 

Add-conditional-decision 41 
Add-info-to-node 20 
Add-new- feat, nre 13 
Add-problem 42 
Add-unconditiona.l-dccision 40 
Adjust-agenda 47 
Adjust-and-add-rcusc 17 
Assign- resources- to-sched u le 30 
Calcu late- Direct- Effort. 2 1 
CaI<:uIn.to-Indirccl.-( ost 22 
Cal c u 1 ate- e (Tec t- an d - cos l.s 20 • 

Change- conditional -decision 38 
Change-old- feature 1 5 
Change- problem 43 
Change -11 n conditional-decision 30 
Copy-generic 16 
Create- additional- new- tasks 1 8 
Create-and-add-ncw-Uvsk-problem 1 0 
Customer- requirement- resolution I 
Delete-decision-and- replace 27 
Delete-old-feature I 1 
Exploring-needs 6 
Find-and-a.dd-rcusabh'-node 26 
Generate- problems 35 . 

I m piemen t- meeti ng- decisions 37 
Internal-development 2 
Locate- decision 46 
Locate- parent 45 
Locate- problem 44 
Ma.ke-dccision- using- alternatives 36 
Make-nodo-and-add-in fo 28 
Modify-or-create-new-tivsk 1 l 
Modify-task-node 12 
Pick- node-link 25 
Read-document 0 
Read -justification 1 0 
Read-node- description 21 
Requironients-defi nition 6 


Review- agon da. 48 

R eview- meeting- reports-and- progress 33 
Revicw-ieports-a.gcnda.-and-schedulc 34 
Seiect-and-read-nodc 23 
So ft ware- development 3 
Solve-problem 32 
Transfer- task- to- problem-space 3 1 
Understand-problem-links 7 
Understanding- needs 4 
Visit-a.nd- rea.d-node 8 


of> 
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. FEATURES 

(terminals) 

add-agenda-problem 

add-justification 

add -reuseable- node 

a.dd-to-gcncric-list 

add-to-modify-Iist 

add-to-new-list 

add-to-not.es 

add-to-out-Iist 

a, dd-to- report 

add -to- reuse-] 1st 

ad d- u p-d i rcc t - cos ts 

add- up- in direct- cost 

adjust-justification 

adjust- reuse- ta.sk- problem 

browsing-agenda 

calculate-node-size 

calculate- risk-effort 

calculate- task-probJerns-efTort. 

calculate- task-problems- risk 

ealeu late- task- prohle ms-size 

calculate- total-uode-size 

change-description 

conditional-decision 

copy-new-generic- task-problem 

create- new- problem- node 

create- new- task-problem 

create- task- problem 

decision 

delete- agenda.- problem 

delete-problem 

delete- task- problem 

dependency-down 

dependency-up 

describe-alternatives 

describe-problem 

document-view 

cmacs-comm ands 

fill-in-description 


get-closure-list-justify-to-form 

get-effort- risk-size- estimates 

get- parent- node 

give-justifications 

justification-from 

justification -to 

koy-siibproblems 

link-justification 

locate- problem 

locatc-decision 

locate- parent 

make- dec is ion 

make- new - re placemen t 

modify- a go ml a- problem 

problem 

produce-schedule 
read-description 
research- problem 
re view- agenda 
review- report 
review-sclied nle 
scroll- view 
select- alter natives 
skip 

switch - view 

ta ke- agenda.- problem 

task 

terminate- at- node- closure- relevant- nodes 
t rans for- ten tat i ve- to- problem -space 
u ucondil . ion a.I- decision 
write-aiid-lin k-docn men tat ion 
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ATTACHMENT #2 


Primary draft of the Process 
Model for porting 



Process Model 


Writing Transformations 

Reengineering -> taskCU > (Porting I Enhancing | Translating) > system 
Porting -> UnderstandingMA, SE > d . task_root : d . task_problem 

AssessmentMA, SE > d.task__root > Change_decisions >d.task_root 
Assign__resourcesMA, SE > d. schedule, d. agenda 
Task_problem_solvingSE > { d . task_problem} 

{d. agenda, d. schedule > Solve_jproblemsSE > d. agenda 

Review_meet ing > d.meeting_notes 

Implement_meeting_decisions > d . schedule, d . agenda 

Understanding -> Get__f amiliar 

Get_familiar -> (First_pass | Addit ional_pass ) 

First_pass -> (Read_manual | Sample_target I Compile_target ) 

Assessment -> /* for read_manual choice */ 

sour ce_manual : manual > read_appendixSE > 
idiosyncracies_source : idiosyncracies 
target_manual : manual > read_appendixSE > 
idiosyncracies_target : idiosyncracies 
idiosyncracies (source/target) : idiosyncracies > compare_dif f erencesSE 
> list_of__transf orms : transforms 
list_or_transf orms : transforms > Task_problem_solving 
Task_problem_solving -> 

or iginal_source : source > r.open > r.astiast 
FORMAL L x in list_of_transf orms : transforms { 
x> { wr ite_single_transf ormat ionSE 
te st_tra ns format ionSE 
(debugSE | done) } > 

transf ormation_rule_list : transformation } 
transf ormation_rule_list transformation > G^nerate_target 



Process Model 
Using Transformation 


:ate_target -> 

transf ormation_rules : transformation > run_rulesSE > 
target_source : source 

move_target_compile > ( list_or_errors I clean_compile) 

FOR ALL errors in list_of_errors { 

errors> { (write_trouble_reportSE I fix_manuallySE) } 


Process Model Objects 


Source = {lines of source code} 


Manual = (reference guide, users guide, etc.) 

Idiosyncracies = {language grammar rules or examples 

specifying machine specific 
implementations } 

Ast = {abstract syntax tree} 


Transforms 


{mapping of idiosyncracies from one machine to 
another } 


Transformation 


{rule for pattern matching to convert 
existing pattern to new pattern} 



ATTACHMENT #3 


Meeting Notes 



Meeting Report: 1 


Meeting Date: 26 March 1992 

Meeting Location: Old Dominion University 

Computer Science Department 

Attendees : 


Tamara Taylor 


Old Dominion Paramax 

Dr. Kurt Maly Tamara Taylor 

Dr. Christian Wild 
Sooshma Bokil 

A. Opening Remarks: 

Dr. Maly opened the meeting at 2:00 PM. He recommended 
that Dr. Wild send a letter to the dean stating Ms. 

Taylor's status as a student. This is to avoid the 
question of a possible conflict of interest since she is 
the representative from Paramax to the Decision Based 
Software Design/Refinery working group. 

B. Current Status Review: 

No agenda was provided. The following issues/points were 
discussed. 

1. At Dr . Wild's request, Ms. Taylor questioned 
Reasoning Systems as to the possibility of 
recording line numbers in the abstract syntax trees 
(ASTs) for a possible mapping between Refinery and 
Decision Based Software Design (DBSD ) . Reasoning 
does maintain line numbers and offered four 
possibilities for accessing. The line numbers are 
not recorded in the AST. An attribute would need 
to be added in order to map to the decision view. 

lem: Retaining Decision Structure through conversion to AST and back 

2. Assuming the line number attribute is added, Dr. 

Maly questioned how the line numbers would be 
mapped back to the source and decision view once 
the transformation is done. Dr. Wild responded 
that DBSD will have to look at the transformation 
rule to see what happens and of course there will 
not always be a one to one mapping of line numbers 
to attributes as one decision can span multiple 
lines/nodes. He also stated that most 
transformations will probably be semantic 
therefore, decisions will remain across the board. 

Lem: (child of the above) how to maintain precision in the 

^formation process 

3. Another area of concern that was discussed 


Meeting Report 
26 March 1992 
Page 2 

is how will the decision views be affected when 
something is added during the transformation. 
Initial thought is that this will require a manual 


update to DBSD . ,, , 

Diem: also child of the above: how to instrument new code added by 

reformation process. 
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4. Areas of concern for DBSD are: 

a. How to record the decisions that went into the 
transformation rules themselves, 

b. Once the transformation is complete, how will 
the manual fixes be implemented, 

c. When new source is introduced during the 
transformation, what role does DBSD take. 

5. Dr. Maly questioned the ability to start and stop 
during the transformation process and if this is 
possible how integrity would be maintained across 
the views . 

6 The above discussion was in relation to adding DBSD 
to existing applications and to providing hooks 
between DBSD and Refinery. Of another issue is if 
DBSD is already existent in the application being 
transformed. If this is the case, it was reported 
by Dr. Wild that you would have gaps and loose 
precision but not to 3. drestic messure. 

7. Discussion moved to the task at hand for Paramax. 

Ms . Taylor reported that there is a definite need 
in the industry to reuse existing code. Customers 
want to move to take advantage of new hardware 
technologies without redoing software initially. 
Their primary goal is to move to the new "box" then 
revamp using CASE technologies to optimize once 
there There is no acceptance for down time on 
existing applications. This is the driving force 
behind exploring the capabilities of Refinery. 

8. Dr. Maly reported that DBSD is not related to the 
functional view but to the decision view. This 
needs clarification. 

9. Future meetings will be held at 1:30 PM on 
Thursdays with the exception of the next meeting 
which will be on 31 March 1992 at 10:00 AM. 


Meeting Agenda 
2 

31 March 1992 

I. Opening Remarks 

A. Old Dominion 
B . Paramax 

II. Current Status Review 

A. DBSD 

B. Refinery 



III. 


Upcoming Events 


> 

> 

> 

> 

> 


Next Meeting (Proposed: Thursday, 9 April 1992, 
1:30 PM, Old Dominion University) 
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id AA00726; Mon, 20 Apr 92 18:03:36 EDT 
Message-Id: <9204202203 . AA00726@plevin> 

References : <9204202016 . AA2O74O0oswald. cs .odu .edu> 

From: Chris Wild <wild> 

To: Tamara Taylor <taylor> 

Cc: wild, maly, bokil, rosea 
Date: Mon, 20 Apr 92 18:03:36 EDT 
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wl - Reengineering. 

Kurt felt that the wl problem encompasses too many 
issues and that Chris is "prettying up" because 
once documented you are now accountable. Kurt 
feels that the reengineering capability using 
Refinery is a given as that is what the company is 
paying for and should be stated as such. As for 
the alternatives, Kurt was not aware that Refinery 
is being evaluated during this process and the 
possibility exists for Paramax to disband with use 
of this tool if it is not a desirable and cost 
effective approach to reengineering. Tammy stated 
that although this is a remote possibility, the 
possibility does exist after seeing how well the 
transformation process performs and how easy the 
methodology developed will be to implement. The 
decision to use Refine is really dependent upon the 
answers to the following two questions: 
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1. Is transformation methodology appropriately 
mature for use by Paramax? and 

2. If so, is Refine the way to go? 


Tammy stated that Paramax feels relatively 
comfortable that Refine is the best that . is 
available commercially for a transformation 
capability. She also stated that she had spoken 
with James Boyle of Argonne National Laboratories 
who has been working in the transformation arena 
for well over ten years. Mr. Boyle also feels that 
Refine is the best transformation system available 
commercially. He did however, send papers on the 
TAMPR system which is a transformation system he 
works on. Tammy has provided copies of these 
papers to Chris and both he and she are currently 
reviewing from a methodology standpoint. Kurt says 
that when we are writing problems they need to be 
stated as a problem and not as an assertion. 

w2 - Preserve decision structure in AST. 

Let's assume that Refinery is the way to go and we 
are proceeding along that path. W2 addresses 
preserving the decision structure in the AST. This 
requires annotating the AST. Mapping is known 
because Refine is a transformation system. There 
is therefore a tie between the lines being 
processed in the source code and Refine. Refine 
will have to be modified to mark the lines in order 
to determine which transformed lines came from 
which original lines. It was decided after much 
discussion that this was the best decision 
eventhough it will require modifying Refine. Kurt 
questioned whether we should institute as policy a 
requirement for discussion of the alternatives. 

This would only be feasible if it was low cost and 
easily accessible. One possibility suggested by 
Chris was to use audio to record the conversations 
and then you could access as necessary. It was 
decided that audio is not feasible without digital 
access and that is not readily available. It was 
also decided that the alternatives should just be 
expanded sufficiently to state their consideration. 
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w3 - Precision of decision transformation. 

This is an active problem and has no decision as of 
yet . 

w4 - New code added by transformation rule. 

This needs further study. 

w5 - Transformation rule decision views . 
oblem/decisio ns outlined in wl-w6. 

Wl, w2, w5 and w6 are considered root problems and 
w2 has as sub problems w3 and w4 . 

Of issue, is how to integrate DBSD into Refinery 

and to realize that there is not just one decision 

structure. The transformation rules have decisionow how the proc< 

affect our decisions. Tammy has the action item to 

outline this prior to the next meeting. Sooshma 

has the action item to update the wl-w6 decisions 

and links to the decisions prior to the next 

meeting. A point well made during this meeting is 

that there are several process/decision views tnsformation rules, 

3. Decisions concerning code that didn't pass 
the transformation, and 

4. Decisions about the entire transformation 
methodology itself . 

Tammy also has the action item to graph these 
decision views prior to the next meeting, ges of DBSD 
on this task. They are 

1. Once a transformation is performed, use 
DBSD to update what didn't pass the 
transformation rules , 

2 . Use DBSD for new code added during the 
transformation, and 

3 . Use Diews . 

Sooshma will update the decisions and links to wl- 
w6 . 
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16 April 1992 


Opening Remarks 

A. Old Dominion 

B . Paramax 



Meeting Report :3 

Meeting Date : 16 April ,1992 

Meeting Location : Old Dominion University , 

Computer Science Department . 


A. Opening Remarks : 

Dr. Maly opened the meeting at 1.30 PM. 

B. Current Status Review : 

1. Dr. Wild discussed the problems W7 - W1 1 that went into preparing the agenda. 

Coding for W8 (removing from agenda list) and W 11 (adding to agenda list) has been 
done. Cufrently presentation problem is being looked into . 

2. Dr. Maly raised the point of interproject visibility i.e. when a system is being designed 
using DHC as a tool , is the designer allowed to look at 

a) a whole set of decisions 

b) partial set of decisions 

c) no decisions 

that were developed by someone else to develop the tool itself V 

3. The problem of 'how much visibility' of the above point depends on the 'context' of the 
projects. 

Our task is to translate a specific Cobol program into Ada . 

Graphically , Translator 



Cobol Process-model Ada 



DHC 


1 


a) Is the user allowed to change Process-model ? 

b) Is the user allowed to look into Translator ? 

c) Is the user allowed to look into DHC ? 

i.e. when we are solving problems by using solutions of other problems , how much do we need 
know about those solutions ? 

In die next meeting we’ll be discussing about 

a) Translation of decision structure thru’ refinery . 

b) Functions of DHC . 


2 



Meeting Report: 4 

Meeting Date: 23 April 1992 

Meeting Location: Old Dominion University 

Computer Science Department 

Attendees : 

Old Dominion Paramax 

Christian Wild Tamara Taylor 

Sooshma Bokil 

A. Opening Remarks: 

Dr. Wild opened the meeting at 1:30 PM. 

B. Current Status Review: 

The topics on the provided agenda were discussed. 

1. Chris stated that we needed to discuss what was 
needed from Reasoning Systems to connect the DBSD 
structure. It was decided that the grammar is 
definitely needed. Tammy will provide the point of 
contact for this and will additionally ask 
Reasoning if it is possible for them to incorporate 
the line number attribute into the AST. 

2. Tammy provided a handout on the process 
possibilities of Refinery and Refinery with DBSD. 
We went over all ten pages and made changes to page 
5. The area of change is #3 which is the decision 
views attached to the target source including 

a. decision views attached to original source 

b. decision views attached to untransformed 
code 

c. decision views attached to new code 
generated during the transformation 

d. mapping of decision views attached to 
transformation rules to code. 

Please see handout for further detail. We deleted 
3d as although it is still open for discussion, the 
possibilities of implementing this are remote due 
to the robustness of the requirement. We added a 
fifth decision view which encompasses decisions 
made on DHC in order to integrate with Refinery. 
We also discussed 3b as this is a new problem for 
DHC and the area of how to handle this needs to be 



addressed . 
handling 3b. 


There are 
They are 


three possibilities for 
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1. Manually update, 

2. Refinery gives some assistance, and 

3. fully integrated. 

Chris stated that of the three choices manually 
updating is unacceptable. We are net sure what 
assistance Refinery gives at this point. In g 
of this, Tammy has the action item to find out what 
Refinery does with untransformed code. She also 
has the action item to write out the process for 
the development methodology (#15 page 3) 


Action Items: 


Tammy 

will 


will question Reasoning as to whether they 
be able to annotate object base with line 


numbers . 

Tammy will find out 
untransformed code. 
Tammy will provide 
Kestrell/ Reasoning for 
of Refine. 


what Refinery does 

point of contact 
obtaining a university 


with 

at 

copy 


rom taylor Mon May 11 16:18:06 1992 

-VM-v5-Data^< 1 .."w 92 « 6tl8?0 1” "EDT" "Tamara Taylor" "taylor" nil 

eceived: from ceawlin.cs.odu.edu by chrysanthemum, cs . 

( 4 . 1/ server2 . 4 ) id AA01648; Mon, 11 May 92 16.18.01 EDT 
eceived: by ceawlin.cs.odu.edu (4 . l/lanleaf2 .4) 
id AA28824; Mon, 11 May 92 16:18:01 EDT 
lessage-Id: <9205112018 .AA28824@ceawlin.cs.odu.edu> 

'rom: Tamara Taylor <taylor> 

Co : wild 

Date: Mon, 11 May 92 16:18:01 EDT 


Meeting Report: 5 
Meeting Date: 7 May 1992 

Meeting Location: Old Dominion University 

Computer Science Department 


Attendees : 


Old Dominion 

Kurt Maly 
Chris Wild 
Sooshma Bokil 


Paramax 
Tammy Taylor 


A. Opening Remarks: 

Dr. Maly opened the meeting at 1:30 PM. 


B. Current Status Review: 

The topics on the provided agenda were discussed. 

1. We collectively discussed the Ref inery/DBSD process 
possibilities focusing on page 5 of the handout 
provided by Tammy at the last meeting. The outcome 
of the discussion is that we are trying to solve a 
reengineering problem of how to incorporate 
Refinery and DBSd. This task initially encompasses 

the following: 

a. Reengineering problem - Need a system for 
transforming existing applications and for 
recording the decisions involved. 

Solution: Develop REENG a reengineering tool 

incorporating DBSD/Ref inery . 

Project directory /home/dhc/ReEngineering created 

b. DHC Emacs problem - While performing a., 
exercise DHC locating problem areas . 

Solution: Improve DHC by making appropriate 

modifications . 

-- Project directory /home/dhc/version2 /DHC-emacs 

c . Transformation problem - Automate porting 
Cobol code including DHC from one machine to 
another. 

Solution: Write Refinery transformation rules 

to translate cobol and DHC statements. 

— Project directory /home/dhc/version2 /H2HTransf ormation 



d. Instance of c - Verify correctness of 
rules written. 

Solution: Instantiate c by translating 

Meeting Report 5 
7 May 1992 
Page 2 

specific programs from Harris to Microfocos 
arena . 

-- Project Directory /home/dhc/SnapPort 

Action items resulting from this discussion are for 
Tammy to write up problems in the minutes, Chris to 
enter problems into DHC and to teach everyone else 
how to use DHC, and for Sooshma to enter the 
process model for solutions. 

2. Tammy is to ask an additional question of 
Reasoning Systems concerning if there is a syntax 
tree construct that the unparser doesn't 
understand . 

3. The outcome of the meeting was that we appear 
to have a better definition of the problem/problems 
we are solving and a narrower set of tasks from 
which to develop the transformation methodology. 


Action Items : 

Tammy will write up the four problems. 

Chris will enter problems into DHC. 

Chris will teach others how to use DHC. 

Sooshma will enter process model for solutions. 
Tammy will correspond with Reasoning on specific 
questions . 


Meeting Agenda 
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14 May 1992 

I. Opening Remarks 

A. Old Dominion 

B. Paramax 

II. Current Status Review 

A. DBSD 

B. Refinery 

III. Upcoming Events 

Next Meeting (Proposed: Thursday, 21 May 1992, 1:30 
what happenend to this thursday? 


c? 



Meeting Report: 6 


Meeting 

Meeting 


Date: 14 

Location : 


May 1992 

Old Dominion University 
Computer Science Department 


Attendees : 

Old Dominion 

Kurt Maly 
Chris Wild 
Daniella ?? 


Par amax 
Tammy Taylor 


B. 


Opening Remarks: 

Dr. Maly opened the meeting at 1:30 PM. 

Current Status Review: 

The topics on the provided agenda were discussed. 

1 . We discussed necessary revisions to a paper that 
will appear in a software magazine this fall. The 
naner describes how DHC is used in the DBSD arena. 
Kurt would like to see more comments the P a P®^ 

about what the benefits of using DHC are. It was 
decided to replace the term ••documentation' with 
"project memory" throughout the paper . It was also 
decided that the paper needs more hard facts By 
this we mean to state that we are using DHC and how 
it is providing us with a multiview of our problems 
and decisions. Add i t iona lxy , one example needs ° 
be given and expanded throughout the paper. Kurt 
would also like to add tables and diagrams as they 
will more than likely entice interest and prompt 
reading of the verbiage. One high point f ° r cred ^ 
worthiness is to state claims of which we are 
claiming that using DHC will save you some number 
of man years in performing maintenance on a 
project. We want to stress in this paper that DHC 
provides a connected system from the specifications 
through the coding effort and the ability to 
retrace your decisions and their benefits and/or 
side effects. Daniella and Tammy will participate 
in updating this paper. Tammy will provide the 
commercial side as to the numbers of man years that 
are spent on maintenance etc. and Daniella will 
become the resident expert on the underlying 
program structure of DHC. 


2 . 


Discussion moved to the task Tammy is undertaking 
to initially use Refine to port Cobol from one 
machine to the other. Kurt sees no need for 
transformation rules for this task. He believes 
that the syntax tree will not change and that there 
is therefore no need for a rule. He also doubts 
that there is an unparser. Tammy of course 
disputes this and says that we do have an unparser 
and that there is a need to do a transformation 
rule at this stage eventhough this appears to be a 
simple problem. Tammy is tasked to question 
Reasoning about this. 

The action items from last week will continue to be 
worked on as the problem layout is complete but 
instruction still needs to be given on DHC and the 
solution process still needs to be modeled. 


Action Items: 

Chris will enter problems into DHC. 

Chris will teach others how to use DHC. 

Sooshma will enter process model for solutions. 
Tammy wil] correspond with Reasoning on specific 
questions . 

Next meeting: (Proposed Thursday 21 May 1992, 1:30 

PM Old Dominion University) 


From taylor Fri Jun 26 11:21:29 1992 

X-VM-v5-Data : ([nil nil nil nil nil nil ml nil nil] „ 

[nil nil nil nil nil nil nil nil ml ml ml ml From. 
Received: from horsa.cs.odu.edu by chrysanthemum cs.odu.edu 

(4 . l/server2 . 4) id AA14825; Fri, 26 Jun 92 11:21.28 EDT 
Received: by horsa.cs.odu.edu ( 4 . 1/ lanleaf 2 . 4 ) 
id AA05775; Fri, 26 Jun 92 11:20:54 EDT 
Message-Id: <9206261520 .AA05775@horsa.cs.odu.edu> 

From: Tamara Taylor <taylor> 

To: bokil, maly, rosea, taylor, wild 
Date: Fri, 26 Jun 92 11:20:54 EDT 


nil nil nil] ) 


Meeting Report: 8 

Meeting Date: 24 June 1992 

Meeting Location: Old Dominion University 

Computer Science Department 


Attendees : 

Old Dominion 

Kurt Maly 
Chris Wild 


Paramax 
Tammy Taylor 


A. Opening Remarks: 

Dr. Maly opened the meeting at 1:30 PM. 

B. Current Status Review: 

Please note that there have been no minutes provided for 

6/10/92 and 6/17/92 meetings. 

1. Tammy reported on her trip to Reasoning Systems for 
advanced training. She said she feels more 
comfortable with the tool but that it is a large 
tool with varied capabilities and there is still a 
lot to learn. She did perform some transformations 
while she was in class on code specific to her 
task. She additionally held the line numbers from 
a D HC file and feels she will be able to transform 
the” needed information from the D-HC files. She 
will be completing the transformation rules for her 
specific task immediately as well as ^ looking at D- 
HC for where it will be useful in this project. 

Discussion proceeded to our goals for the summer 
which include all parties (Daniella, Soosma and 
Tammy) being familiar with both D-HC and Refine. 
Tammy is the process model and Refine person and 
Daniella is the D-HC person. It is not yet 
determined where Soosma will concentrate her 
efforts. Daniella will get the next iteration of 
D-HC up and running in this time frame as well. At 
the end of the summer, we will have a more concrete 
process model and will know how both D-HC and 
Refine can be utilized on a project. We will 
evaluate them separately and as a package. 

The agenda for the next meeting will concentrate on 



I . 


II . 


reviewing the process models for the machine port 
and for embedding SQL statements into ported code 


The action items to be completed prior to the next 
meeting are: 


1. Kurt, Chris and Tammy will review existing 
process models and update/detail accordingly. 


2 Tammy will obtain email address for Chris for 
persons to contact that are using Refine in classes 
being taught at Oregon State, Naval Post Grad 
School and Air Force Institute of Technology 
(AFIT) . 


3 Tammy will obtain status on slip protocol 
connection as it needs to be completed prior to 
running windows across the modem. 


4. Chris should provide an update on the paper 
which is to be published in the fall. 


{ 
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1 July 1992 


Opening Remarks 

A. Old Dominion 

B. Paramax 

Current Status Review (Action Items) 

A. DBSD 

B. Refinery 


III . 


Upcoming Events 


Next Meeting (Proposed: Wednesday, 8 July 1992, 
1:30 PM, Old Dominion University) 



From taylor Thu Jul 2 11:44:01 1992 
Status: RO 

X-VM-v5-Data : ([nil nil nil nil nil nil nil nil nil] 

[nil nil nil nil nil nil nil nil nil nil nil nil ,,A From:" nil nil nil]) 
Received: from penda . cs . odu . edu by chrysanthemum.cs.odu.edu 

(4 . l/server2 . 4) id AA08112; Thu, 2 Jul 92 11:43:59 EDT 
Received: by penda.cs.odu.edu ( 4 . 1/lanleaf 2 . 4 ) 
id AA09462; Thu, 2 Jul 92 11:44:16 EDT 
Message-Id : <920702154 4 . AAO 94 62@penda . cs . odu . edu> 

From: Tamara Taylor <taylor> 

To: maly, rosea, taylor, wild, zhang_j 
Date: Thu, 2 Jul 92 11:44:16 EDT 


Meeting Report: 13 
Meeting Date: 1 July 1992 

Meeting Location: Old Dominion University 

Computer Science Department 


Attendees : 

Old Dominion Paramax 

Kurt Maly Tammy Taylor 

Chris Wild 
Daniella Rosea 
Jing Yuan Zhang 

A. Opening Remarks: 

Dr. Maly opened the meeting at 1:30 PM. 

Please note for history purposes that these minutes 
represent our thirteenth meeting and that is reflected on 
the meeting report number. Minutes were provided and 
numbered correctly for meetings one through six. No 
minutes were provided for meetings seven through eleven. 
Minutes were provided for meeting twelve but were 
numbered incorrectly as meeting report eight. In the 
future minutes will be numbered according to the 
chronological number of our meeting just as this one is 
numbered thirteen. 

B. Current Status Review: 

Kurt provided a handout with an updated version of the 
reengineering problem and it's sub problems entered in D- 
HC and a process model of the reengineering problem using 
the context free grammar. Discussion revolved around the 
problems/model and the handout was updated accordingly. 

It was decided that the reengineering problem would only 
cover porting, enhancing and translating. It was also 
decided that the first pass of any of the three areas 
would be different than additional passes. It was 
additionally decided that part of the first pass is a 
"getting familiar with" stage. Update to format for 
context free grammar are that we will use activities with 
an agent subscript and objects will be denoted with a 
tool and a period (e.g. d. convention for something D-HC 
knows about, can modify or produce.) Daniella will 
update the D-HC problems and Tammy will update the 
process model. 



The agenda for the next meeting will concentrate on 
reviewing the updated D-HC problems and the updated 
process model. 

The action items to be completed prior to the next 
meeting are: 

1. Daniella to update problem definition in C-HC. 

2. Tammy to update process model. 

3. Chris should provide an update on the paper 
which is to be published in the fall. 

4 . Tammy to provide updated status on email 
addresses for instructors of Refine. 
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8 July 1992 


I . Opening Remarks 

A. Old Dominion 

B. Paramax 

II. Current Status Review (Action Items) 

A. DBSD 

B. Refinery 

III. Upcoming Events 

Next Meeting (Proposed: Wednesday, 15 July 1992, 
1:30 PM, Old Dominion University) 
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Meeting Date: 8 July 1992 

Meeting Location: Old Dominion University 

Computer Science Department 


Attendees : 


Old Dominion 

Kurt Maly 
Chris Wild 
Daniella Rosea 
Jing Yuan Zhang 

A. Opening Remarks: 


Paramax 
Tammy Taylor 


Dr. Maly opened the meeting at 1:30 PM. 
B. Current Status Review: 


It was decided that we need a process model for D-HC that 
xs more reflective of what is existing and what is to 
exist in the next iteration. The current D-HC process 
model is an ideal model that is to be worked toward but 
is not reflective of the current state. Discussion 
centered on this topic with several action items beinq 
assigned. Additionally, we defined a process model as 
being rules of interaction among the agents of chanqe be 
they tools, humans, etc." We will also need D-HC to 
incorporate a view of the process model in the decision 
view so that you can assess where the process model needs 
to change when a change occurs in a tool/function modeled 
by the pr° cess model. This view also needs to be 
filtered according to individual needs. 


The following action items resulted from this meeting: 

1 * Chris will provide a list of what will be added to 
DHC from the existing process model and a previous 
functional grouping. 

2. Chris will propose what functionality will be 
provided for next iteration and will work with 
Daniella and Jing Yuan on updating the process 


3 . 


Chris will rearrange the existing 
structure to accommodate Kurt's 
reengineering problems/process model. 


directory 
proposed 
He will 


4 . 


5. 


6 . 


7 . 


8 . 
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working with it. 

. , , enter onto the agenda 
Daniella and Jing Vuan wil docun ,entation and of 
the task of Panting out ^ additionally work on 

filtering views. Thy itemg thou gh not pn 

the code for 
the next meeting. 

Everyone will Keep clivTtUs^nd 0 recort th^when, 

mat is involved. 

ri-HC from one 

Eurther discussion needed L on reuse ^ nQt? 
ta£ lc to another. Will this 

Everyone will use O-HC and . -coj. ^^ar 0 “ “th. 

^ssrss^r^^ ^ to use « 

get familiar with. 

Next meeting is Thursday, July 16, 1992, 2.30 p.m 
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• rom taylor Tue Jul 21 10:10:29 1992 
(a: maly. rosea, taylor, wild, zhang j 


Meeting Report: 15 

Meeting Date: 16 July 1992 

Meeting Location: Old Dominion University 

Computer Science Department 


Parama* 

[jmay Ijylor 


Attendees : 

Old Ooamion 

Kurt Maly 
Chris Wild 
Oamel la Rosea 
Jing Yuan Zhang 

A. Opening Remarks: 

Or. Maly opened the reeling at J:UU IM. 

B. Current Status Review: 

Chris hid listed the existing tunct ion. I i t y of U-MC ilong 
with i propose l of -hat should be provided in he next 
iteration. Ihe proposal -as discussed and -ill be 
elaborated on at the next meeting. 

It -a decided that reuse of tasks in 0-llC -ill 
laple^ented in the next iteration. It -as also •?* , d U 
that the proble. and decision space in U-HC should be 
separate. Additionally. « need a tor. for recording 
what -e are working on in order to gainer statistical 
information while working outside of 

We will review the updated process model at the ne«t 
meet mg . 

The following action items resulted rrom this meeting: 

1 Chris will provide a hard copy and/or file naee of 
the updated process model which contains misting 
funct iona lily. 

2 Chris will provide a hard copy and/or file name of 
proposed fund iona 1 i ly for next iteration of 0-HC. 

3 OanielU will move all dependency and justification 
links related to the problem to within the problem 
space. These will be separate from the decision. 

4 Tammy will provide a for. to be reviewed at the 
next meeting which will aid in recording what they 
are working on in relation to 1>-Mt/Hef meiy . Ihis 
is to be used to statistical purposes. 




\S 


Ihe following action items remain from 


i he d July 92 


■eel ing : 


3. Chris will rearrange the existing directory 
structure to accoaaodate Kurt’s proposed 
reengineering prob leas/process aodel. He will 
additionally input the problems and process eodel 
into Q-HC as a deao to those of us -ho w ill be 
working with it . 

4. Daniella and Jing Yuan will enter onto the agenda 
the task of printing out documentation and of 
filtering views. They will additionally work on 
the code for these two tleas though not prior to 
the next aeeting. 

5. faaay will update the process aodel according to 


20 19:32 1992 standard input Page 2 

the standard conventions and will rework -s «“* 
according to specific objects. 

8. Everyone will use 0-HC and become taailiat so as to 
•ake recoaaendat ions for update. Use the 
-/dhc/deao directory and •reset*’ prior to use to 
get fa* i 1 iar with. 

Note: Next aeeting is Wednesday, July 22. 1992. l:ju p.». 
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22 July 1992 


1 . Opening Reaarks 

A. Old Ooatnion 

B. Paraaax 

||. Current Status Review (Action Ilea*) 

A. OBSO 

B. Refinery 

III. Upcoaing Events 

Next Meeting (Proposed: Wednesday, 29 July 1992, 
1:30 PM, Old Ooainion University) 




The first topic discussed was how do we logg objects 
that we manipulate and the activities we accomplish, 
especially when we are outside DHC . Here we have to 
make a decision about the fact that the tool should w 

support everything (including outside DHC) . 

The form we need should state the activities, the time 
spent on each of them, the order of activities. We have 
to choose between: 

1. a form of the process model and checkout the steps 
that I am doing. 

2. a list of the terminal activities from the process 
model. In this case I loose the sequence of activities 
and the objects on which I do the activities. 


Another topic of the meeting was the visibility of the 
decisions, i.e. if we make a decision on a transformation 2 + 

rule do we make it visible on the target code? 

Also we have discussed the subject of identifying a problem 
at one level and solving it at another level ( the system's 
or the user's levels) . We haven' made a decision yet on 
this subject. 


On this subject Chris has come with an example: the variables 
in a cicle in FORTRAN. What to do? I can write a transformation 
rule for that and tell the user about it, or do it automatically 
(without telling anything to the users) and realize that this 
thing may be inefficient for a user that doesn't need this 
facility too much. 

It should exist the possibility of filtering the views or part 
of a view I'm interested to see. 


The following action items resulted from this meeting: 

1* Daniela and Jing Yuang will continue to work on the agenda 
functions in order to extend the actual facilities of the 
system. 


2. Tammy will update the form she presented as we have discussed. 
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sting Report: 19. 

eting Date: 9/23/92 
eting Location: ODD 

.tendees : 

ODU: 

Kurt Maly 
Daniella Rosea 
Chris Cowles 
Chenglin Zhang 

, Chenglin (Lin) was introduced. Names and passwords 

^e me efcha 9 „ge; 9an NB: <c»les> <rosca> <maly> <zhang_c> <taylor> 

>ermissions are needed for Cowles ^sfbe^Sdefto the Y " faculty" Email 

jee A jay to see that it is aone. 

irily began a discussion on the minutes of the previous S/SSSS 

hat Che phrase (found under B : ^chart P-ble^ ^ ^ deve loped» . over th. 

“CCCofth^is^K following points were made: 

-Definitions of DBSD and tt-h^tneering ^Refinery^were «|h a “ d 0DU *I; ^ 

ll.TttolLr SofCCCus^C^nery” we wish to use both of these m a unrf. 

environment . two pe< 

-A problem: in porting source-code pother : ^^J n ® d icision views" in sou: 

(say the user and the porting engineer) may have <1^ same source code ? For examp^ 

How do we support di ^ f ® rent . ^^^atched to it; it depends on who is viewing it (t) 

are shown with this 

-In the above example, we do not wish to have both operat^^ B is it then tu: 

— ^heCser ^Ls^hC^ S,SS»S.. need to loot at the code and 
decisioC structure from the user's point of vrewl, 

The following points S observations were also made: 

to be entered into the problem space and agenda A. 
-All project problems are to oe 

POMP UP 

-we need to evaluate DHC; make it more stable and useful enough. Possrbly . 
some functionality . 

-Make problem descriptions more in depth from now on. 

-Add to the chart what Daniella has done. 

-Make and keep notes regarding conditional decisions; add to the DHC code s. 
that we are able to backtrack decisions. 


The meeting was quickly ended at 3:15 pm, 


as we all 


rushed off to the colloquium. 



From rosea Wed Oct 14 10:41:16 1992 
To : maly 

Subject: meeting notes21 

Cc: rosea, cowles, taylor, zhang_c 

Meeting Report: 21 

Meeting Date: 7 October 1992 

Meeting Location: Old Dominion University 

Computer Science Department 


Attendees : 


Old Dominion Paramax 

Kurt Maly 
Chris Wild 
Daniella Rosea 
Chris Cowles 
Chenglin Zhang 

A. Opening Remarks: 


Dr. Maly opened the meeting at 1:30 PM. 

B. Current Status Review: 

First we have discussed the deliverables for this phase of the 
project. They will be: the paper from '91, the paper from ' 92(IFIP) 
the vrewgraphs for boths and the meeting notes. 


In this meeting we have discussed the objectives of our project 
for the following months to come. Basically, we have addressed the 
topic of the integration of DHC and Refinery. We have two 
possibilities : make them loosely coupled, seeing each other like a 
black box that executes its job sequential in time with respect to 
the other tool or make them tightly coupled. 


To answer this question we have to answer first the question: are 
the transformation rules built using DHC or Refinery? If we use 
DHC for writing the transformation rules we will use Refinery 
a ^'- erwar< ^ s as a compiler for the transformation rules . 


For a tightly coupled version we will need to embed DHC in Refinery 
to consider each of the Refinery functions as black boxes and wrap 

DHC functions, if they are sufficiently small. Also we would 
need that this functions be noninteractive so that we can have the 
control of the user actions at the DHC level. For this we would need 
a deep understanding of the source of Refinery, to figure out how 
to make the link with DHC. We would need from Paramax a detailed 
list of capabilities and functions of Refinery. 


Dr. Wild said that from the discussions with Tammy resulted that 
from the past and current experience it seems to be no need for 
9 u? COUpled version. Anyway we need to ask them again and to 
thoroughly analize which are the gains from writing the 

transformation rules in DHC and which are the gains from writing 
them in Refinery. * 


q !f est:L ° n that we have to ask Paramax is if they want to 
support also the reverse porting, in the case when is needed an 
enhancement in the ported program. Do they want to maintain the 
1 versions of the program consistent, so we should have the 
capability of going back and forth between the 2 versions of a 

program, or once we have done the porting, the older version will 
not be considered anymore. 


From the discussion resulted the following guide lines for the 
future development of DHC : 

- add the filters for different views: 

- for porting engineers 

- for enhancing engineers 

- for project managers 

- develop new evaluation methods, new measures to have automatic 
statistics. 

- to enhance the existing process model. 
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7 October 1992 


I. Opening Remarks 

A. Old Dominion 

B. Paramax 

II. Current Status Review (Action Items) 

A. DBSD 

B. Refinery 

III. Upcoming Events 

Next Meeting (Proposed: Wednesday, 14 October 1992, 
1:00 PM, Old Dominion University) 


cowles Wed Oct 14 14:49:36 
osca 

ct; las t meeting ^ thin k there is more 

. mites i've written so far. t x don't expect 

nclosing the minute t admit, i l^st didn t q • comments. 

X SvisSn thit ™* 


Meeting Report: 22 


Meeting Date: 14 ^”00 University 

Meeting Location. ^ neoartment 


Attendees : 

Old Dominion 

Kurt Maly 

Daniella Rosea 
Chris Cowles 
Chengli n Zhang 


Paramax 


, „ai y opened the meeting at — - s 2) co „ ti „uing with 

sis end Lin ere on~ently 1> ^HC^mo* it Maly 

----- - dhc - 

de structure, end 3) be needs to n gather 

niella ia to P» ‘ t “f £*«*« fcover' letter^ end 3 ) 

! November°f irst^ls^th^target date to submit thus 

sport. , - _ to a conflict. 

S -sswss sssrsus: •• 

he time being. t c ode . Our tasks is 

aramex' s test (i a , J^eL/outpurin^ha^ver form, o «—o^Jt. # tha ^ 
rocess oftranslc ,rmin< , it In^ f/f ^K^ol tor porting - to complete 

he° transport at ion o £ that .COBOL, program. (far amex 

ffnrM we would like to hear involved, 

is regards our marketing e ^ how many languages an 

lavy) about such things a do we face the 

writing down all 

Droblem of knowing ^ether of a larger P ro ^ 1 ®* S know the entire 

- iHS^re SJTiarjir. t0 «a note that 

every S problem ieing^olved is tied to a reguiremen. 

• w ^ havp well-defined tasxs cu u / 

si „ ce we all seem at this point to have 
meeting was ended at 2:1 pm- 


1:10 PM. 
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Received: by ramses.cs.odu.edu (4 . 1/lanleaf 2 . 4 ) 
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From: Daniela Rosea <rosca> 

To: maly 

Subject : meet 23 . notes 

Cc : rosea, cowles, zhang_c 

Status: R 

Meeting Report: 23 

Meeting Date: Oct. 21 1992 

Meeting Location: Old Dominion University 

Computer Science Department 


Attendees : 

Old Dominion Paramax 

Kurt Maly 
Daniella Rosea 
Chris Cowles 
Chenglin Zhang 

A. Opening Remarks: 

Dr. Maly opened the meeting at 1:00 PM. 

B. Current Status Review: 

We looked over the report and cover letter prepared by Daniela for 
Paramax. We need to add a table of contents and a complete chart of 
the Reengineering problem with the corespondence between problems 
and descriptions. 

In the report we have to put explicitly references to the 
attachements of the document and to have separate chapter for each 
main topic . 

We have also discussed the specific questions to ask Paramax about . 
They concern mainly market information needed in taking our decisions. 


The following action items resulted from this meeting: 

1. put togheter the chart of the Reengineering problem. 

2. upgrade the report according to the chart. 

3. ask Tammy all the information necessary for completing items 1 and 
2 . 
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Oct. 21 1992 


I . Opening Remarks 

A. Old Dominion 

B. Paramax 

II. Current Status Review (Action Items) 

A. DBSD 

B. Refinery 

III. Upcoming Events 

Next Meeting (Proposed: Wednesday, Oct. 28 1992, 
1:00 PM, Old Dominion University) 
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Meeting Report: 24 

Meeting Date: 28 October 1992 

Meeting Location: Old Dominion University 

Computer Science Department 


Attendees : 

Old Dominion 


Kurt Maly 
Daniella Rosea 
Chris Cowles 
Chenglin Zhang 


Paramax 


r. Maly opened the meeting at 2:15 PM. 

aniella, Chris and Lin prepared a chart of the reengineering problem space 
hich we had defined so far for the meeting. The following discussion was 

ased on the chart. 

r. Maly pointed out that some problems, such as market future and the process 
,f reenigneering to Paramax, were missing and reemphasized the importance that 
svery problem, whether it is currently linked or not, should go into the chart. 

'he evaluation of dhc, Refinary, and process model is not the problem of re- 
•ngineering. As far as reengineering is concerned, we have to study its 
nethodology , process model, and supporting tools. We have to make a decison 
>n such alternatives as 1) use dhc alone; 2) use Refinary alone; 3) use them 
3 oth. If we choose the last alternative, we have to decide if they are looselycoup^. 

In a loosely-coupled approach, we have to 1) upgrade dhc; 2) get more knowledge 
on Refinary; and 3) determine the interface between dhc and Refinary. Here we 
—Moron Refinary; and 3) determine the interface between dhc and Refinary. Here we 
need more information from Tammy: 

1) reengineering process in Paramax; 

2) pros and cons of Refinary. 

We spent some time on how to reuse solutions if the coming problem is the same 
as or similar to a problem in the problem space. Cut-and-paste seems to be a 
good strategy. Anyway, we have to make out how to build the reuse machanism 
into the dhc or Refinary process model. 

We reached the following convensions for our future charts: 

1) The text in every node of the chart should contain the name of the corrres 

reference between the chart and .pd/.dd files. 

2) The up and down links in decisions (UL and DL) will be dropped out because 
all the information will be organized around the problem space and there are 
in fact no links between decision nodes. 

3) We do not have to require that every problem node has a corresponding 
decision node. In fact, we make a decision only when there are several 

4) We 1 ” may add some mark symbols to problem nodes to indicate their solution 
status . 


poi 


Some problems remain: . . _ 

1) How to generate unique identities for problems and decisio 
practice in dhc is to use the first character of login name 
This should be changed. 

2) How to show output of problem solving in the chart. 


. The current 
with a number . 


3) How to sort the problem and decision spaces according to some specific 
criteria . 

Because there are some things unclear to us about market and Paramax, we will concei 
chart. We will have an upgrated chart for the next meeting. 


The meeting was ended at 3:50 pm. 



Meeting Report : 25 

Meeting Date: November 13, 1992 

Meeting Location: Old Dominion University 

Computer Science Department 


Attendees : 

Old Dominion 


Kurt Maly 
Daniella Rosea 
Chris Cowles 
Chenglin Zhang 


Paramax 


Tammy Taylor 


Dr. Maly opened the meeting at 9:30 am. 

The focus of this meeting was to review and update the Chart and Report to 
be sent to Paramax. 


Re P° rt ' a Ta t>le of Contents is needed; previous meeting notes and 
the Chart are to be included. In the Chart, our problem is the DBSD paradigm 
and what we are doing for the Paramax Reengineering problem. Paramax problems 
include: what's a reasonable tool for porting/enhancing/transformation, and the 
need of a Market Study to decide how much to emphasize each. We have chosen, 
as of now - due to the unavailability of a Market Study, DHC and Refinery, 
loosely coupled. 


As for the Chart ' s alternatives , we will add only the major ones, 
need to shade in (in xfig) all the outputs. We will "freeze in" 
in the Chart as part of the overall Report. 


We also 

today's changes 


Some items not yet addressed in the Chart include: 1) using it as a quick 
reference to problem decisions, and 2) adding problem names in the existing boxes 
to be used as an index. All of the attachments for the Report are ready. 

^ r o ? UeSt ^° n „ fo £. Tairm y / Paramax include: Are there any Reengineering contracts 
as of now? How big are they? How many LOC are involved? What are the problems 
in the other solutions and what are their characteristics? 


As far as the actual submission to Paramax is concerned, an invoice is to be sent 
under separate cover and should reference the deliverable. 


Tammy will be here on Tuesday to help Daniella with the Chart; we will meet 
again on Wednesday at 1:30 to make final adjustments; the package will be sent 
on Thursday, November 19th, 1992. 


The meeting was ended at 10:30 am. 



ellmina ry Draft : 11/18/92 


ATTACHMENT #4 


Primary draft of the chart representing the 
problems involved by the reengineering process 



Chart of the Problem Space for Reengineering 






















How many council of these types 
actually exist at Par am ax aui which 
arc their characteristics? 
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Location of a problem in the problem space 
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Draft: 11/18/92 


attachment #5 


DHC problem and 


decision spaces 



&&rl 
P : 
UL: 
DL: 
DL: 
DL: 


?R.05ceM SPACE Y€* P tL 

reengineering__problem 1 

Develop a methodology and supporting tools to port applications from a source i 
apply_and_improve_DBSD_methodology 
porting_problem 
translating_problem 
enhancing^problem 


&&r2 reengineering_process_model 

P: Develop a process model for porting, translating and enhancing applications 

UL: simple_porting 

DL: process_model_implementation 

DL: process_model_notations 

DL: get_Ref inery_process_model 

DL: get DHC_process_model_f or_Rengineering 

DL : combine_DHC&Rf inery_process_models 

&&r3 evaluation_problem 

P: validate the decision in reengineering_j?roblem 
UL: simple_porting — 

DL: logger 

DL: statistical analizer 


&&r4 logger 

P: Log the activities (as defined in process model) of all participants. 

UL : evaluat ion_problem 

DL : logging_f orm_representation 

&&r5 statistical_analizer 

P: Analize the data of the logger 

UL: evaluation_problem 

DL: analyze_log__on_JProcess Model 

DL : analy ze__log_on_Unif ied__Environment 

DL: analyze_log__on_DHC 

DL: analyze_log_on_Re finery 


& &r 6 apply_process_jnodel_to_transf ormation task 

P: a. port a SNAP COBOL program running on a Honeywell to a UNIX box running Micr< 
b. replace the file operations with an equivalent database language 
UL: simple_porting 
DL : demonstrate_pro cess 
DL : demon'strate_DHC 
DL : demonstrate_Ref inery 
DL: demon st rat e_Unified Environment 


&&w2 Preserve_decision_structure in AST 

P: If refinery is used to transform one source code document into 
another, then any decision structure associated with the first 
document needs to be transferred to the second. 

UL : interf ace_between_DHC&Ref inery 

DL : Precision_of_decision_transf ormation 

&&w3 Precision_of_decision_transf ormation 

P: How is the precision of decision structure maintained through the 
Refinery transformation. Since the AST is not line oriented, the 
decision view don't map one for one on the AST 
UL: Preserve_decision structure in AST 
DL: “ ~ 


&&w4 new_code_added_by_transf ormation rule 

P: How is . new code added by transformation rule to be instrumented 
for its decision structure? It is possible that this new code solves a 
problem of differences between platforms or compilers (an accidental 
difference by Fred Brooks classification) . 

UL : process_model_implementation 



DL: 


&&w5 transf ormation_rule_decision_views 

P: How to record the decisions involved with defining the 
transformation rules themselves. 

UL: process_model_implementation 
DL: 

&&w6 manual_after_transformation 

P: How to support manually processing that occurs after the 
transformation. Also how does the programmer understand what the 
transformation system has done? 

UL : process_model_implementation 
DL: 


& &r 7 tool_f or_upgrading__DHC 
P: What tool to use for DHC? 

UL : upgrade_DHC 
DL: 

Sl&. r8 robustness_of_DHC 

P: What criteria should we use for choosing a tool for DHC? 

UL: 

DL: 

& & r 9 order_of_ob jects_editing 

P: How to edit 2 objects in order: describe problem and agenda object? 
UL : 

DL: 

& & rlO insert_agenda_list 

P: Insert a problem into the agenda list. 

UL: upgrade__DHC 
DL : 


& &r 11 modif y-agenda-list 

P: modify entries of a problem in the agenda list to reflect the status of problei 

UL: upgrade_DHC 

DL: 


&&r 12 entry_def in it ion 

P: Entry definition in DHC files. 

UL : upgrade_DHC_quit 

DL: 

& & r 13 f ield_def inition 

P: Identification of fields in an entry in DHC files. 

UL : upgrade_DHC_quit 

DL : empty_field_def inition 

&&rl4 empty_f ield_def inition 

P: Which is the definition of an empty field? 

UL : field_def inition 
DL: 

& & 1 5 apply__and_improve_DBSD_methodology 

P: apply DBSD methodology to various applications and eventually improve it, as a 
& &r 1 6 long__term_goals 

P: Reuse problem, include some AI techniques, etc. 

UL : apply_and_improve_DBSD_methodology 



DL: reuse_j?roblem. 


&&rl7 reuse_problem 

P: How to reuse actual solutions from our problem space to solve new problems 
UL: long_term_goals 

&&rl8 AI_applications 

P: Apply some AI methods, techniques to DBSD 
UL : long__term__goals 

&&rl9 porting_problem 

P: porting applications from one machine to another 
UL : reengineering_problem 
DL: simple_porting 

&&r20 enhancing_problem 

P: enhancind the features of an application 
UL : reengineering_problem 

&&r21 translate_problem 

P. translate from a language A to another language B, on the same machine 
UL : reengineering__problem 

& &r22 simple_porting 

P: support onlu simple porting from one source machine to a target machine 

UL: porting_problem 

DL: market_study 

DL : reengineering_proces_model 

DL : CASE_tool_f or_reenginerring 

DL : apply _j?rocess_model_to_transf ormation_task 

DL: evaluation_problem 

&&r23 complex__porting 

P: support both porting and reverse porting 
UL: porting_problem 

&&r24 market_study 

P: we need more information from a market study done by the Paramax 

personnel to gide our efforts into the direction desired by paramax. 

UL: simple_porting 

DL : reengineer ing_contr act s& character is tics 
DL: reengineering_solut ions & char act eristics 

&&r25 reengineering_contracts&charact eristic 

P: how many reengineering contracts exist at Paramax and which are their 
characteristics ? 

UL: market___study 

&&r 26 reengineering_solut ions & character is tics 

P . what other solutions have been used till now for the reengineering 
projects and which are their characteristics 
UL : market_study 

& & r27 process_model_implement at ion 

P: issues in the actual implementation of the process model of Paramax 

UL : reengineering_process__model 

DL : new_code__added_by_jtransf ormat ion rule 

UL : transformat ion rule decision views 

DL : manual_af ter__transf ormation"" 

&&r28 notations_f or_process model 

P: notations to use in a formal specification of the process model 
UL: reengineering_process_model 

& &r29 get_Ref inery_process_model 

P: get the process model for Refinery use in this problem 



nd h 


reengineering_J>rocess_model 


■ probiem “ here ue have used 

logging forms on Process Mode! 

,. s tatistical_analizer 

Unified_Environment 

L: s tatistical_analizer 

34 a a nS^e e 5 ie 9 d“s D cbtain with the logging forms on DHC 

,L: statistical_analizer 

’ 33 analyze 6 the 9 da ta^obtain^ with the logging forms on Refinery 

jL: statist ical_analizer 

36 demonstrate_process ooegs model o£ the 0H c methodology and the 
: develop & protouyp P 

'uL^°apply_P r ocess_mod e l_to_transf ormation_task 

;r31 demonstrate_DHC protot ype to determine the value of DHC 

p : develop an upgra transformation task 

UL: applyJprocess_model_to_trans 

sr38 demonstrate *.fin«y o£ using Refinery for this type of problems 

UL reapply ^ptocess^odei^to^trans format ion_t ask 

of-T-ate Unified Environment , f >.j environment fron the 

[&r 39 demonstrate unir — f bui iding a unified envi 

P- demonstrate the utility 

Ln UL' a applyjrocess"model"to_transformation_task 

EHC^with the updating of the agenda list 

UL : upgrade_DHC 

DL: entry_def inition 

DL: field_def inition 

p • how 9 to* 9 represent r the 9 login 9 forms? 

log-UE, log-DHC, log-Refinary 

ttz2 log-RM login form for the porting Process Model. 

OL^logging-f orm-representat ion 

DL: 

ssz3 log-UE in form for the United Environment? 

UL^ logging” form- represent at ion 

DL: 



&&z4 


&&z5 


&&z6 


& & z 7 


&&z8 


&&z9 


&&zlO 


&&zll 


& & z 1 2 


& & z 1 3 


&&zl4 


& & z 1 5 


log-DHC 

P:How to represent login form for DHC? 

UL: logging-form-representation 
DL: 

log-Ref inary 

P:How to represent login form for Refinary? 

UL: logging-form-representation 
DL: 

CASE-tools 

P:What kind of CASE tools will be employed to support the porting? 

UL : simple-porting 

DL : dhc-ref inary-integration 

dhc -refinary- integration 

P: How to integrate DHC and Refinary? 

UL: CASE-tools 

DL : loosely-coupled 

loosely-coupled 

P : How do we build a loosely coupled system for the porting? 

UL : dhc-ref inary-integration 
DL : Unif ied-Environment 

Unif ied-Environment 

P:What should we do to build a Unified Environment? 

UL : loosely- coupled 

DL : upgrade-DHC, understand-Ref inary , interf ace-between-DHC-Ref inary 
upgrade-DHC 

P : How to make DHC more robust and stable enough? 

UL : Unif ied-Environment 

DL : decision-views , problem- solving- levels, problem-locating, 
conditional -decisions, dhc -evaluation -enhancing, unique -names , 

understand-Ref inary 

P: We should have a good understanding about Refinary before we could 
integrate DHC and Refinary. 

UL : Unif ied-Environment 
DL: 

interf ace-between-DHC-Ref inary 

P: How do we build the interface between DHC and Refinary in a 
loosely- coup led Unified Environment ? 

UL : Unif ied-Environment 
DL: 

dec is ion- views 

P: In porting source-code to another machine (say, A to B) , two person 
(say the user and the porting engineer) may have different "decision 
views". How do we support different decision structures on the same 
source code? 

UL : upgrade-DHC 
UD : view-filtering 

view- filtering 

P:It should exist the possibility of filtering the views or part 
of a view I'm interested to see. We should support view-filtering 
for porting engineer, project manager, and other users. 

UL : decision-views 
DL: 

problem-solving-levels 

P:How do we support problem-solving at different levels? We should be 
able to identify a problem at one level and solving it at another 



& & z 1 6 


&&zl7 


&&zl8 


&&zl9 


level (the system's or the user's levels). 
UL : upgrade-DHC 
DL: 


problem-locating 

P: w p n f ^ t ^JJ g dow £ a11 Problems in the overall Problem Space: do 
T? f w i he P^ odlem of knowing whether or not this problem has 
already been defined in the Problem Space? Is a Problem part of 
a arger Problem Structure? Where does it fit into the Problem 

s ® ems one has to know the entire Problem Space 

in order to know where this Problem fits in ^ 

UL: upgrade-DHC 
DL: 


conditional -decisions 

P: kee P n ° tes regarding conditional decisions; add to the 

DHC code so that we are able to backtrack decisions. 

UL : more-dhc-f uct ionality 
DL: 


dhc -evaluation -enhancing 
P: How to enhance DHC evaluation methods? 
UL : 

DL : evaluation-methods 


unique-names 

P: How to generate unique identities for problems and decisions 
The current practice in dhc is to use the first character of" 

UL^pgiade-DHc" * ^ ±S t0 ° ” Gak and should ** Ranged. 

DL: 



Q 


i c . 




J3CC.VS4 OlO *S PA. Cj£ 

&&rl reengineer ing_problem 

ffS — 

J : Dictated by : 

a. the availability of DHC and Refinerv* Hi- will 

b. validation of the above decision matter ° f evaluation 

UL : reengineering_jDroblem 


&&r2 

A1 


A2 

D : 

J: 

UL 

DL; 

C: 

&&r3 
A1 : 
A2 : 

D : 
J: 
UL 
DL 
C: 


reengineering_process_model 

: Develop separate methodologies for: 

^ different dialects of Pdrot ta m u it 

b. Enhancing applications (e7 usina of ^n' Honeywell to Microfocus) 

c Translating into another language ( e Q g COBOL^Ada?^ ° f f±le ° peratio1 
: Develop a general methodology for everything. Ada) 

Al) 

■ ^engineer ing^process^modei nderSCO ° d '° fUlly develop a general methodology fo: 
We assume that the existing application is partially DHC-ed. 

evaluation problem 

Wave onr£:r e bo L S^pUoati“s iStiCal - analy2er f ° r «engi„eering_process_model 

DeVel ° P °" e L ° 99er a " d °" e ^ tat i s tical_analyzer and apply them to solving , 

: evaluation_problem 


& &r 4 
Al : 
A2 : 
A3 : 

D : 

J: 

UL: 

DL: 

C: 


logger 

Keep a notebook of activities j-nni rr , . 

Collect information by instrument!™ DHC^f ' 6 Start ' end ' Product s (sour 

: Combination of 1 and 2 . inStrumentini ? DHC, Ref rnery, project accounts, UNIX. 

A3) 


&&r5 statistical_analizer 

Site of v«io" S p„« a ofdoo nd USe duration). 

A3: Amount of ne„ parts vs. changes"in existing^ne^' rUleS ' S0UrCe C ° de: 


UL: 

DL: 

C: 


&&r6 apply_process_model_to_transformation_task 


r* • d/ 

J: 

UL: 

DL: 

C: 


&&w2 Preserve decision structure in AST 
A: 

1) Manually reconstruct the decision structure 

2) transfer the decision structure into the AST (Abstract 
Syntax Tree) 

3) semi-automatic match of old and new to transfer 

D: A2 

J : A1 is too labor intensive,, A2 should be possible since 
information about the line numbers if available during the parse. In 
fact they seem to use this information in linking the AST to the 
source code. If the line numbers were kept in the AST, then the 
decision views would also be known (LINK to decision to have as the 
least granularity of a decision the line) . 

UL: 

DL: 

C: 

&&w3 Precision of decision transformation 

A: 1) don't worry about it, the mapping will be close, use whatever 
line numbers is available. 

2 ) 

D : 

J: 

UL: 

DL: 

C: How mush of a problem is this? 

Since no decision was made initially, this should remain on the agenda. 

&&w4 new code added by transformation rule 
A: 1) don't add any decisions 

2) don't add any but notify the user (keep on the agenda) 

3) add from the transformation rule if accidently difference 
handled by the rule 

4) add decision from the union of the AST of the old 

5) same as 4 but only if one view 

D: A3 maybe - this is a conditional - need further study 
J: 

UL: 

DL: 

C: 

&&w5 transformation rule decision views 

A: 1) don't need to, there aren't that many 

2) use DBSD as normally 

3) Cross link to transformed system 
D : 

J: 

UL: 

DL: 

C: 

&&w6 manual after transformation 

A: 1) Use DBSD to record any decisions 

D: 

J: 

UL: 

DL: 

C: 

&& 



&&r5 tool_for_DHC 

A1 : use Emacs in files .dd, .pd, .al (agenda list) 

A2 : create a dedicated editor 

D: Al) 

J : programming ease 
UL: 

DL: 

C: 

& &r 6 robustness_of_DHC 
Al : Programming ease. 

A2 : Robusteness . 

D: Al 

JUL: tool_for_DHC 
UL: 

DL: 

C: 

&&r7 order__of_ob jects_editing 
Al : write our own interpretor 

A2 : check consistency every time we use a DHC command 
A3: check consistency on exit 
A4 : rely on user to be "nice". 

D: A3 

J: In dhc_quit we check the . dd and . pd files for consistency of the objects. 
Check every field and modify in the Agenda Status. 

UL: 

DL: 

C: 

&&r8 insert_agenda_list 
A : 

D: For each problem, put the following entries: 

&&<problem-description-name> : 

\tDate Entered: <the time when the probelm was entered> /filled automatically 
\tDue Date: <the time when the problem will be solved> ; blank initially 
XtResponsible Engineer: <the person responsible for solving this problem> ; in 

the person who created the problem 

XtPriority : <an integer ranger from 0 to 100, 0 - lowest and 100 - highest>; b 
\tStatus : ; Currently there is only the "Empty Fields" sub-entry 

\t\tEmpty Fields: <the blank entries of the problem in DHC.pd and DHC . dd> ; al 
XtComments : 

J: provide whatever is needed. 

UL : describe-problem 
UL: make-decision 
DL: terminal 
C: 


&&r9 modify-agenda-list 
Al : modify automatically. 

A2 : let users do it. 

D: A2 

J: simple, and some entries such as "Priority" can not be set automatically. 
UL: insert-agenda-list 
DL : terminal 
C: 


&&rl0 entry_def inition 
A: 



D: an entry starts with "&&" 

J: For an easy identification of the entries. 

OL: 

DL: 

C: 

rll field_def inition 

D: An entry field begins with TAB@@. 

J: For identification purposes. 

UL: 

DL: 

C: 

rl2 empty_field_def inition 

Al: Just a CR. 

A2 : Without any character. 

D: Al- need to be validated later. 

J: 

UL: 

DL: 

- C: 

&zl 


&z6 


St z 7 


;&z!3 


locrainq-f orm-representation 

A:l) a form of the process model and checkout the steps 
that I am doing. 

2). a list of the terminal activities from the process 
"model. In this case I loose the sequence of activities 
and the objects on which I do the activities. 

D: 


The form we need should state the activities, the time 
spent on each of them, the order of activities. 


CASE-tools 
A: l)use DHC alone; 

2) use Ref inary alone; 

3) use both DHC and Refinary; 

4) Use other tools. 

D:We choose the third alternative, 
J 


dhc~ refinary- integration . , i t v-o a black box 

A: 1) make them loosely coupled, seeing each other like a black box 

that executes its job sequential in time with respect to t 
other tool. 

2) make them tightly coupled. 

D : 

C-For a tightly coupled version we will need to embed DHC in Refinery, 
"to consider each of the Refinery functions as black boxes and W ^P 
them in DHC functions, if they are sufficiently small. Also we would 
need that this functions be noninteractive so that we can have the 

control of the user actions at the DHC level. For this we would need 

a deep understanding of the source of Refinery, to figure out ho 
to make the link with DHC. We would need from Paramax a detailed 
list of capabilities and functions of Refinery. 

A • ^We^do°not wish to have several operations active at the same time; 
e. only Hen tL cod, is completely ported to the target machine 

then is it turn over to the user (from porter s view to the user s 

view) . 



UL: 

UD: 

C: 
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ATTACHMENT #6 


Process model for traditional life cycle of 
software notations specific to DHC 



Notations 
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— > - is defined as 

Capital - a label for a subspacc of the process model space - an intermediate symbol 
- a set of activities done often enough to merit its own name. 

lower - name of an object either needed for an activity or produced by an acliviiy A 

> - indicates data (object) How (input or output) 

Capital^ - subs is the person normally engaged in this activity 

boldlowcr - functionality available in DHC or process model 

[ ] - repeat 0 or 1 lime 

( } - repeat 0 or more times 

I - alternate paths in subspacc 

activity i II activity 2 - activities which can be done in parallel 
activity { "blank 1 ’ activity 2 - activities which arc done in sequence 
( ) - used for grouping, but docs not assign an intermediate name to it. 

/♦comment*/ - can be used anywhere in process model to help explain 
namc:objcct - names an instant of an object in the process model 
V {objects} > Activity - perform activity for all objects in set in random order 
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Process Model Objects 

Software = {lines of source code] 

Documentation = (problcm_spacc, decision_sct, documents, juslification_rcIation, dcpendcncy_rclation, 
decision_rclation, altcmatc_rcIation, task_rcIation, description relation, vicw_rclation) 

Documents = (requirements, specification, design, source) 

AItcmate_relation = (problem x problem) 

Justification_relation = (problem x problem) 

View_rclation = (problem x document) 

Dcpcndcncy_rclation = (problem x problem) 

Dccision_rclation = (problem x decision) 

Task_reIation = (problem x taskjiroblcm) 

Dcscription_relation = (problem x probIcm_dcscription) 

Works_with_rclation = ((manager, task), (soflwarc_cnginccr, problem)) 

ProbIcm_spacc = (problem) 

Decision_set = (decision) 

System = (software, documentation) 

Environment = (DHC) 

Schedule = ((task, problem, person, status, priority)) 

Agenda = ((problem, progress information)) 

Session = documentation^^g-documentation^^i^ 

Problem_dcscription = ((description, alternates, decision, justification), attributes: (abstractionjcvci, 
generic, user_filtcr, size, rcusejist)), 

f* generic: a node in generic if it is contained in all alternatives of its father*/ 

/* user_filten used to create user defined filter*/ 

f* notes: arc created during the understanding and assessment phase*/ 

Size = (# problem, # LOC, # documentation, # filter (documentation)) 
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Task_probicm = (problem, (reuse Jist, generic Jist out Jist, modify Jist, ncwjist) 
risk, effort, lower bound: size, upper bound: size)) 

/* task is a request from either the customer or the manager to change some aspect of the externally observable 
behavior of die system. Adaptive task - change a requirement; perfective task - change decision In a problem; 
corrective task - change software and/or documentation of a problem node whose solution is incorrect It is 
represented by a probIcm_dcscription*/ 

Persons = (MAnager, SOftwarc_cnginccr, Customer) 

Report = {lines of text) 

Mccting_notcs = (lines of text) 
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Process Model for Traditional Life Cycle 
Detailed Description 


External customer Requirement ^resolutioncu **> task^y > (Soflwarc_dcvcIopmcnl 
1 1 Customcrjccdback) > system 

Internal _perfection_and_correctioncu t MA ~ > las ^cu.MA > Soflwarc_dcvelopmcnt > 
system 

SoflwafC_dcvclopment ~> task > {Understandings* 

Understandings^ >/*rcquircmcnts_dcfinition*/ task_root: task_problcm 
/* I ist_of_rcusab!cs candidates*/ [ problem ) , 
Task_problcm_solving > /* first Jcvel_dccom position*/ {task_probIcm), 

[Assessment MAtS £ > (task_rool, effort, task_root.sizc, task_rooLrisk) Changc_task_dccision > task_root) 

Assign_rcsources > schedule 

Transfer iask_tojprob!cm_spacc > agenda 

{agenda; schedule > Solve ^problem SE > agenda 

Rcvicw_mccting > mccling_notcs 
Implcmcnt_rnccting_dccision > schedule, agenda) 

Under standing MAt sE ~> Exploring \\addjo_report MASE > report 

Exploring --> Rcquircmcnls_dcfinition II Rcusability_scarch 

Rcquircmcnts.definition --> (keywords > Iocate_probIem > rclcvant_nodcs: (problem), 

make_new_requirement) > task_root_probIcm 

V relevant_nodcs > Understand ^problem 

Undcrstandj)roblcm -> problem >{(Visit_nodc dependency_up > problem) 

I terminate_at_node_closure_relevant_nodes 
I back) 

/*cxploration*/ (justification_from > problem 
I justification Jo > problem 
I dependency jip > problem 
I dependency jiown > problem) 

Visitjiodc — > problem > readjiescription document_view Rcad_documcnt Read Justification 

Rcadjiocumcnt — > {(switch_view f* special view: file view */ 1 problem I decision I 
back I scroII_view I emacs_commands)) 

Rcadjustification — > V (justification to & justification_from) (readjiescription I Visitjiodc) 



Task_problcm_solving --> task_root > (V node € rclcvant_nodcs) (Modify_cxisting_nodc > {lask_problcm] 

( Laskjoot > Crcatc_additionaI_ncw_task > task^problcm}) 

Modify_existing_node --> node > create_task_problem > task_problcm, laskjclation 
tag_subproblems Modify _problcm_nodc 

Modify jproblcm_nodc — > node, task_problcm > (Add_ncw_fcaturc I Dc!ctc_old feature 

I Changc_oId_fcaturc I Copy gcncric 
I Add_rcusc /* for all nodes on reuse list) 

Add_new_fcature — > node, tnskjproblcm > change-description add_justification 

create_new_task_probleni 

add_to_new_Iist 

DeIcte_old_fcaturc — > add_to_out_Iist 

Changc_old_fcature — > node, task_problcm > change_description adjust justification 

create_new_task_problem > modify_nodc, modify_task_problcm > 

Modify_probIcm_node 

/* stop decomposition of modification at point where it is possible to estimate sizx */ 
add_to_modify_list 

Copy_gcncric — > change_description adjustjustifications copy_new_generic_task_problem add_to_generic_list 

Add_rcusc — > change_description adjus trustification adjust_reuse_task_problem add_to_reuse_l*st 

Crcale_additionai_new_tasks — > createjiewtaskproblem 

FirsHcvcl_dccomposition > task_prob!cm 

First_lcvcI_dccom position --> task_problcm > (create_new-task_problem add_to_new_Iist] 

/* create decomposition problem nodes for each task problem node and tag (create a list of) them as generic: to be 
used in all alternative solutions, out: not to be used in the new task, reuse: to be used with minor modification, new: 
a new feature is to be added to the original solution, modify: one or more subproblcms have to be added, deleted, or 
changed */ 

Assessment --> CalcuIatc_Dircct_Effcct Calculatc_Indircct_Cost Rcvicw_Da/ 0 * M 

Calculatc_Dircct_Effcct ~> (V task e (taskj)roblcm))(V task_nodc e task.gcncric n task.out n task. reuse) 
calculate_node_size calculate_risk_effort > (task_nodc) 

(V task_node € new) effort SE risk SE > getjlTort_risk_size_estimates > {taskjiode] 

(V task_node e modify) Assessment > (task_node) 

(taskjnodc) > calcu!ate_task_problem_size > task 

/* for each category add the number in the subproblcm nodes to obtain the relevant figures in the task problem node*/ 

(task_nodc) > calcu1ate_task_problem_effort > task 
/* this is the sum of the efforts in the subproblcm list */ 

(taskjnodc) > ca!cuIate_task_prob!em_risk > task 
/* the sum of the risks in the subproblcm nodes */ 
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( task} > add_up_direct_costs > task_root 

CalculateJndircct_Cost -> relevant_nodc > get^closurejistjustificationjojrom > ripplcJisL {problem} 

(/* got the worst possible impact by calculating the transitive impact closure for the justification limits */ 

V (node e ripplcjist) ca!cuiateJotal_node_size > { task jproblcm. upper J>ound} 

/* add up all the metrics, # problems, #LOCS, etc, for all the nodes in the closure */ 
l* allow for interactive estimates */ 

I (V node e ripplcjist) (read_description (calcu!ateJotaI_node„size I skip)) > {task_probIcmJowcrJ>ound} 

/* add only selected nodes to the calculation */ 

{taskjjroblcm} > add_upjndirect_cast > taskj-oot 

Review_Data — > (([rclevant^nodc], (task_problcm), task_root, ripplcjist) > Pick_nodc read_description) 

Pick_nodc — > dependency_up I dependency_down I justification Jo I justification Jrom I task 

Rcusability_scarch — > addreusablenode > task_problcm.rcuscJisi 

f* during exploration when finding candidate for reuse, add to reuse list of relevant node 
which is first in up chain of node in questions *f 

Change jask_dccision --> (task_probicm > delete task_problem > node 

(node > Modify_cxisting_nodc I iask_problcm > Crcatc_addiLional_ncw_task) > task_problcm) 

/* delete a task problem and all its descendants and replace it with an alternate solution 
to the relevant node in the problem space or with an altogether new task node*/ 

Crcalc_additional_ncw_task — > task_root > Makc_node > task_problcm 

Make_nodc — > node > create_new_problem_node > ncw_nodc > AddJnfojo_nodc > ncw_nodc 

AddJnfojo_nodc — > (fillJn_description I link Justification I make_dccision I write_andJink_documentation) 

Assign_rcsources — > produce_schedule MA > schedule 

/* it is left to the managing system used to derive schedule from assessment data*/ 

Transfcrjask_problcm_spaccjo_task_root — > taskj-oot > transfer JentativeJo_j>roblem_space > task:prob!cm, agenda, 
visiblc_altcmalivc 

/* transfer all task problems and their sub problems to the problem space, removing existing problems, documenta- 
tion, source code which are to be modified but saving them on an alternative list for possible reuse. All new prob- 
lems are added to the problem space. All incomplete problem nodes arc added to the agenda. */ 

Solve_problcm — > agenda > take_agenda_problem > nodc:problcm 
AddJnfo_lo_nodc 

(Makc_nodc > ncw_nodc Solvc_probIcm) 

Adjust_agcnda > agenda, report 
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F any incomplete node has to be added to agenda and those completed can be taken off (to be saved in report) */ 

1 1 add_to_report SEMA > report 

F notes on activities arc added to a report *f 

I research_probIems SEMA > report 

F rcscarch needed to solve problems or prepare for the review meeting arc done according to whatever system is 
prescribed and results in knowledge how to proceed with the Solvc_problcm activities or in a report for a meeting. 
This includes preparing a print-out of differences in decision graph, source and documentation. */ 

Revicw_mceting ~> (Rcvicw_rcports {(Gcncralc_probIcms I Makc^dccision)} Rcvicw_progrcss) 

I I add_to_notes $e ,ma > mccling_noics 

Revicw_rcports — > (review^report MA SE I review_agenda MA SE I review_scheduIe iWi 4 t< s £ ) 

Gencratc_problcms ~> {describe_probIems 5 £ I describe^alternativesjf I give_justifications je) 

Make_dccisions — > (unconditionaI_decisions se,ma I conditional_decisions sema ) 

ImpIcment_mccting_dccisions — > (Changc_dccision I Add_unconditional_dccision I Add_condilional decision I 
Add_problcm) 

Changc_decision — > locate_decision delete_prob!em > node 
/*nodc is the parent of the problem deleted */ 

Make_node > new_nodc 
Add_info_to_nodc > ncw_nodc 
Adjust_agenda > agenda 

Add_unconditional-dccision — > Iocate_decision Adjust_agcnda > agenda Add_info to node 

Add_conditional_dccision — > locate_decision Addjnfo_to_nodc get_parent_node > node 
Make_nodc > ncw_nodc 

F create problem node for instrumentation problem */ 

Add_i n fo_to_node 
Adjust_agcnda > agenda 

Add_problcm — > Iocate_parent > node 

F fmd the place in the problem space where this problem should go */ 

Makc_node > ncw_nodc 
Add_info_to_nodc 
Adjust_agcnda > agenda 

Adjust_agcnda ~> add_agenda_problem I de!ete_agenda_probIem I modify_agenda_problem 
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ATTACHMENT #7 


Logging form 







